Why Isn t Group Policy Applying?

Why Isn't Group Policy Applying?

At times, you set up Group Policy from upon high, and your users or workstations are not receiving the changes. Why might that be the case?

First, remember how Group Policy is processed :

• The GPO "lives" in the swimming pool in the domain.

• The client requests Group Policy at various times throughout the day.

• The client connects to a Domain Controller to get the latest batch of GPOs. (Group Policy isn't somehow " pushed " from up on high.)

• If nothing has changed on the GPO, the default behavior is to not reprocess the GPOs (though this can be changed as explored in Chapter 3).

• The client-side extensions then process the GPOs that need processing.

That's the long and the short of it.

Now, if you think all this is happening properly, try to answer the following questions to find out what could be damming the proper flow of your Group Policy process.

Reviewing the Basics

Sometimes, it's the small, day-to-day things that prevent a GPO from applying. By testing a simple application that has normal features, you can often find problems and eliminate them, which allows Group Policy to behave the way you expect.

Is the Group Policy Object or Link Disabled?

Recall from Chapter 1 that there are two halves of the Group Policy coin: a computer half and a user half. Also recall that either portion or both can be disabled. Indeed, a GPO itself can be fully disabled (see Figure 4.14).

Figure 4.14: You can disable the entire GPO if desired.

Check the GPO itself or any related GPO links. Click the Details tab and check the GPO Status setting. If it is anything other than "Enabled," you might be in trouble.

Tip 

If you change the status of the GPO, that status changes on all links that use this GPO.

Are You Sure about the Inheritance?

Recall that Group Policy flows downward from each levelsite, domain, and each nested OUand is cumulative. Also recall that there is only one Local Group Policy for a computer, which is applied first.

Multiple Group Policy Objects at a Level

Also recall that there can be many GPOs at any level, which are applied in the reverse orderthat is, from bottom to top, as described in Chapter 2. Since any two (or more) GPOs can contain the same or even conflicting settings, the last-applied GPO wins. If you mean for one GPO to have higher precedence, use the Up and Down buttons to manipulate the order. Remember, the GPO with the lowest number gets the highest priority. Confusing, I know, but that's the deal.

Examining Your Block Inheritance Usage

The GPMC gives you a quick view of all instances of Block Inheritance with the Blue Exclamation point (!). Remember: once you select to block inheritance, all GPOs from higher levels are considered null and voidnot just the one policy setting or GPO you had in mind to block. It's as if you were starting from a totally blank slate. Therefore, whenever you block inheritance, you must start from scratcheither creating and linking new GPOs or simply linking to existing GPOs already swimming in the GPOs container. Note, however, that the special functions the Default Domain Policy GPO performs cannot be blocked. (This GPO is discussed in Chapter 6.)

Examining Your "Enforced" Usage

Conversely, be aware of all of your "Enforce" directives. The Enforce icon is a little lock next to the GPO link. "Enforce" specifies that the policy settings selected and contained within in a specific GPO cannot be avoided at any inherited level from this point forward. When "Block Policy Inheritance" and "Enforce" are seemingly in conflict, "Enforced" always wins. Recall that Enforced was previously known as "No Override" in the old-school parlance.

Are Your Permissions Set Correctly?

Recall from Chapter 2 that two permissions"Read" and "Apply Group Policy"must be set so that the affected user processes a specific GPO. By default, Authenticated Users have these two rights, but you can remove this group and set your own filtering via the "Security Filtering" section on the Scope tab of a GPO link.

In Chapter 2, I showed you two ways to filter:

• Round up only the users, computers, or Security groups who should get the GPO applied to them.

• Figure out who you do not want to get the GPO applied to them, and use the "Deny" attribute over the "Apply Group Policy" right.

When all is said and done, users will need both "Read" and "Apply Group Policy" permissions on the GPO itself to apply GPOs. Having only one of those permissions means that Group Policy will not apply when processing is supposed to occur.

Additionally, make sure to remember that the "Deny" attribute always trumps all other permissions. If an explicit "Deny" attribute is encountered , it is as if it were the only bit in the world that matters. Therefore, if a specific GPO is not being applied to a user or a group, make sure that "Deny" isn't somehow getting into the picture along the way.

Warning 

Any use of the Deny bit is not displayed in the "Security Filtering" section of the Scope tab; so you really have no notification if it's being used. I predict this will be a common reason for Group Policy not applying; the old-school way to perform Group Policy filtering involved heavy use of the Deny bit, and now the GPMC will not easily display this fact.

Advanced Inspection

If you've gone through the basics, and nothing is overtly wrong, perhaps a more subtle interaction is occurring. See if any of the following questions and solutions fit the bill.

Is Windows XP's Fast Boot On?

The default behavior of Windows XP is different from that of Windows 2000. The default behavior of Windows 2000 is to process GPOs synchronously. That is, for the policy settings that affect a Windows 2000 computer (which will take effect at startup), every GPO is appliedlocal, site, domain, and each nested OUeven before the user has the ability to press Ctrl+Alt+Delete to log on. Once the user logs on, the policy settings that affect the user side are appliedlocal, site, domain, and each nested OUbefore the user's desktop is finally displayed and they can start working.

But the default behavior of Windows XP is to perform nearly everything asynchronously. Asynchronous Processing means that GPOs can process out of their natural order. The GPOs are simply downloaded in the fastest possible manner at any level in Active Directory and then immediately applied. The Group Policy application happens without regard to the natural order.

This usually isn't too much of a problem for the policy settings within GPOs that affect computers, but it can seriously affect your user's experience if enabled for user policy processing. Even after a user is logged on, GPOs can suddenly be downloaded. and policy settings start popping up and change the user's environment.

Moreover, as I stated in Chapter 3, by default, several key items in Windows XP take between two and three reboots to become effective. To that end, I suggest you modify the default behavior. The strongest advice I can give you is to create and link a new GPO at the domain level. Name your new GPO something like "Force Windows XP machines to act like Windows 2000," and enable the Always wait for the network at computer startup and logon policy setting. Then, choose to Enforce it so it cannot be blocked.

To find this policy setting, drill down through Computer Configuration ˜ Administrative Templates ˜ System ˜ Logon branch of Group Policy. (For more information, see Chapter 3.)

Therefore, if you have erratic Group Policy application ( especially for Software Installation, Folder Redirection, or Profile settings), see if the Windows XP default of Fast Boot is still active.

Is Asynchronous Processing Turned On in Windows 2000?

Windows 2000 was born with a way to try to act like Windows XP and process GPOs asynchronously. However, doing so is not recommended as amazingly unpredictable results can occur. Windows XP was built from the ground up to do asynchronous processing; Windows 2000 really wasn't. And to that end, the ability to turn on asynchronous processing has been removed by means of normal policy settings via ADM templates (since Windows 2000 SP3). In other words, if you're managing your Group Policy infrastructure with a machine with Windows 2000 service pack 3, Windows 2003 or XP, you will find no policy setting that can enable Windows 2000 Asynchronous Processing anymore. But if you're still using an older Windows 2000 system to manage Group Policy, you will see a policy setting that could enable Asynchronous Processing for Windows 2000 machines. In a nutshell , don't use it. If you are using it, turn it off.

Note 

Asynchronous Processing is independent for both the computer and the user sides.

Are Both the GPC and GPT Replicated Correctly?

As stated in the first part of this chapter, Group Policy is made up of two halves:

• The GPC, which is found in Active Directory and replicated via normal Active Directory replication

• The GPT, which is found in the SYSVOL share of one Domain Controller and replicated via FRS to other Domain Controllers

Both the GPC and GPT are replicated independently and can be on different schedules before converging. Only after they converge is the GPO available to be applied to the workstation.

Additionally, according to some Microsoft documentation, the GPC and GPT version numbers must match before workstations will apply them, though I haven't found this to be the case.

Use the techniques described earlier in conjunction with Gpotool and Replmon to diagnose issues with replicating the GPC and GPT.

Did You Check the DNS Configuration of the Server?

In order for the GPC and GPT to actually replicate correctly, the DNS structure must be 100% kosher at all times. If you suspect that the GPC and GPT are not being replicated correctly, you might try to see if the DNS structure is the way you intend. If it is, I don't specifically recommend you rip it all up and reconfigure it if everything else is working.

In some cases, one Domain Controller might not be providing Group Policy to your clients. In the next section, I'll show you how to find out if your clients are really logged on and, if so, what Domain Controller the computer and user are using for logon.

If the Domain Controller they're using does not provide Group Policy, one somewhat radical remedy is to point the DNS client of the "broken" server to the same place where other "working" Domain Controllers are pointing. If this doesn't help, you might consider dropping your Active Directory integrated DNS to a standard primaryI've seen kooky things pop up when running in Active Directory integrated mode.

The purpose of these two radical changes (which you shouldn't do lightly) is to jump-start the broken Domain Controller into working and playing nicely with others. Ordinarily, if a specific Domain Controller isn't giving out the GPOs you expect, the GPC and/or the GPT aren't making it there, and DNS is almost certainly to blame.

Are You Really Logged On?

Windows XP and Windows 2000 perform the logon function differently. Specifically, when a user logs on to a Windows XP machine, Windows XP might or might not have made really made contact with a Domain Controller to validate that user and give them a Kerberos ticket to the network. Ker-beros is the newer authentication mechanism that has supplanted NTLM. Windows XP will try its darndest to speed things up (again) and log on with cached credentials. Windows XP will then try to contact a Domain Controller and get the Kerberos ticket for the user.

In Windows 2000, it is easy to identify the Domain Controller where the local desktop authenticated. You issue a set command at a command prompt and look for the contents of the LOGONSERVER variable, as shown in Figure 4.15.

Figure 4.15: The LOGONSERVER variable shows the Domain Controller where this Windows 2000 client is picking up its Group Policy settings.

In Windows 2000, if you aren't logged on to a Domain Controller, you see the variable set to the local computer name.

Warning 

In Windows XP, you simply cannot trust this LOGONSERVER variable to tell you the truth. Additionally, you cannot trust Windows XP's SYSTEMINFO utility either, which claims to provide this data.

Just based on the way Windows XP does its logon thing, you cannot use these aforementioned methods . XP will simply do a bald-faced lie and say that you are logged on (via the LOGONSERVER variable, with the information from the last Domain Controller it contacted).

With Windows XP, to ensure your user and computer are really logged on the network, you can count on just one toolKerbtray. Kerbtray is found in the Windows 2003 Resource Kit and is small enough to be put on a floppy and run on a suspect machine. When you run it, it puts a little icon in the notification area. If the computer and user have Kerberos tickets, the icon turns green, and you know you're really logged on. However, if the Kerbtray returns a graphic of bunch of loose keys (that, in my opinion, look like question marks), as shown in Figure 4.16, you know you're not actually logged on and, hence, not downloading the most recent GPOs. Again, if you were really logged on, the graphic would be a green ticket.

Figure 4.16: Windows XP's LOGONSERVER variable cannot be trusted. Use Kerbtray instead, which is shown running in the notification area.

In Figure 4.16, you can see several things:

• The computer's network card is disabled (as shown in the Network Connections window).

• The LOGONSERVER variable is set to a Domain Controller (as shown in the CMD prompt window). Feel free to simply say out loud, "If the network card is off, this is bloody impossible ."

• Kerbtray, thankfully, returns that icon of a bunch of loose keys verifying that we're not really logged on.

So, to find out if you're really logged on when using a Windows XP computer, it's "Kerbtray or the highway ." Once you've validated with Kerbtray that the computer has really logged on, you can then use the LOGONSERVER variable to make sure which Domain Controller the Windows XP machine has used. Because, you'll know the truth: whether or not you're really logged on.

Did Something Recently Move?

If a computer account or a user account is moved from one OU to another, both Windows XP and Windows 2000 can wait as long as 30 minutes to realize this fact. Once they do, they might or might not apply background Group Policy processing for another 90 or more minutes! Running GPUpdate (or SECEDIT for Windows 2000 machines) will not help.

However, if you're expecting a specific setting to take effect on a user or computer that has moved more than 150 minutes ago, you'll then need to figure out if the move has been embraced by the Domain Controller the workstation used to authenticate. (See the previous section for information about how to determine the Domain Controller via the LOGONSERVER variable, but make sure you're really logged on!)

You can then fire up Active Directory Users And Computers and connect to the Domain Controller in question, as shown in Figure 4.17.

Figure 4.17: You can always manually connect to a Domain Controller to see if Active Directory has performed replication.

If the target computer's local Domain Controller does not know about the move, you might want to manually kick off replication using Active Directory Sites And Services. If the target computer's local Domain Controller does know about the move, you might want to try logging the user off and back on or restarting the computer. Although using SECEDIT (for Windows 2000 machines) or GPUpdate (for Windows XP and Windows 2003 machines) to refresh the GPO is a good option, it's best to log off and/or reboot the machine to guarantee the computer will perform the initial policy processing as described in Chapter 3.

Tip 

I've seen Microsoft documentation which states that running GPUpdate /force on Windows XP/SP2 machine will "jump start" the machine and/or user account into recognizing that it has moved around in Active Directory. I've done extensive testing, but get inconsistent results. Sometimes it seems to work, other times it doesn't. In short, when a user or computer is moved around in Active Directory, I always re-login as the user, or reboot the computer.

Is the Machine Properly Joined to the Domain?

With Windows 2000, if a device is moved from one OU to another and then the device is rebooted before DC replication occurs, sometimes the device can be bumped out of being a domain member because the "computer trust," also known as a "secure channel," is broken. To see if the computer trust (secure channel) to the domain is damaged, you can use NLTEST , which is in the Windows 2000 Support Tools on the Windows 2000 CD. The verification syntax is nltest /sc_query:domain_name . If the test passes , then you're kosher. If not, you might need to disjoin and rejoin the device to the domain.

Is Loopback Policy Enabled?

Enabling loopback policy will turn Group Policy on its ear: loopback forces the same user policy settings for everyone who logs on to a specific computer. If you're seeing user policy settings apply but not computer polices or if things are applying without rhyme or reason, chances are, loopback policy is enabled. Review Chapter 3 to see in depth how it works, when you should use it, and how to turn it off.

How Are Slow Links Being Defined, and How Are Slow Links Handled?

If you notice that Group Policy is not applied to dial-in users, remember the rules for slow links:

• Registry and security settings are always applied over slow (and fast) links.

• EFS (Encrypting File System) and IPsec (IP Security) policies are always applied over slow links. You cannot turn this behavior off, even though settings found under Computer Configuration ˜ Administrative Templates ˜ System ˜ Group Policy branch imply that you can. This is a bug in the interface as described in Chapter 3.

• By default, Disk Quotas, Folder Redirection, Internet Explorer settings, and Software Deployment are not applied over slow links. Updated and new logon scripts are also not downloaded over slow links. You can change this default behavior under Computer Configuration ˜ Administrative Templates ˜ System ˜ Group Policy, as described in Chapter 3.

Additionally, you can change the definition of what equals a slow link. By default, a slow link is 500Kb or less. You can change the definition for the user settings in User Configuration ˜ Administrative Templates ˜ System ˜ Group Policy ˜ Group Policy Slow Link Detection and for the computer settings in Computer Configuration ˜ Administrative Templates ˜ System ˜ Group Policy ˜ Group Policy Slow Link Detection . Figure 4.18 shows the user settings. If Group Policy is not being applied to your slow-linked clients, be sure to inspect the slow-link definition to make sure they fit.

Figure 4.18: Make sure you haven't raised the bar too high for your slower-connected users to receive Group Policy.

Last, don't forget about your broadband users on DSL or cable modem. Those speeds are sometimes faster than 500Kb and sometimes slower than 500Kb. This could mean that your broadband users might get GPOs on weekends but not when logged on during peak usage times. Therefore, if this happens, set the definition of slow link up or down as necessary.

Is the Date and Time Correct on the Client System?

Time differences greater than 5 minutes between the client system and the validating Domain Controller will cause Kerberos to simply not permit the logon. If you don't have Kerberos, you've got a logon problem, and that's going to yield a Group Policy problem.

Are Your Active Directory Sites Configured Correctly?

Sometimes Group Policy won't apply if a Windows XP client isn't in a properly defined Active Directory site (that has IP information associated with it). With that in mind, check the subnet the client is on, and verify that it is correctly associated to an Active Directory site and that the site has Domain Controller coverage.

Did You Check the DNS Configuration of the Client?

One of the most frequently encountered problems with Windows 2000 is that things just "stop working" when DNS gets out of whack. Specifically, if you're not seeing Group Policy apply to your client machines, make sure their DNS client is pointing to a Domain Controller or other authoritative source for the domain. If it's pointing to the wrong place or not pointing anywhere , Group Policy will simply not be downloaded. As a colleague of mine likes to say, "Healthy DNS equals a healthy Active Directory."

Moreover, in the age of Windows 2003 with its multiple forests with cross-forest trusts, Group Policy could be applying from just about anywhere and everywhere. It's more important than ever to verify that all DNS server pointers are designed properly and working as they should. For instance, if clients cannot access their "home" Domain Controllers while leveraging a cross-forest trust, they won't get Group Policy.

Are You Trying to Set Password or Account Policy Upon an OU?

As you'll see in Chapter 6, certain Group Policy items, namely password and account policy, cannot be set at the OU level. Rather, these policy settings are only domain wide. The GUI lets you set these policy settings at the OU level, but they don't affect users or machines. Well, that's not really true, as you'll see in Chapter 6, but, for the purposes of troubleshooting, just remember that you can't have, say, six-character passwords in the Sales OU and 12-character passwords in the Engineering OU. It won't work.

Did Someone Muck with Security Behind the Group Policy Engine's Back?

As you saw in Chapter 3, there are a number of ways to "go around" the back of the Group Policy engine. Remember, though, that these exploits require local administrative access. However, this implies that users with local administrative access can manually hack the Registry and return their systems to just about however they want. Then, as I've described, Group Policy will not reapply upon background refresh, logon, or reboot. It reapplies changes only when the GPO in Active Directory has changed.

Windows 2000 uses the SECEDIT command to refresh Group Policy, but, as I've stated, it still won't forcefully reapply all the settingseven if the /enforce switch is used (which just forcefully reapplies security settings). Windows XP's GPUpdate command will refresh changed Group Policy as well, but its /force switch is quite powerful and will reapply all settingseven those that have not changed.

Is the Target Computer in the Correct OU? Is the Target User in the Correct OU?

This is my personal sore point. This is the one I usually check last, and it's usually what's at fault. That is, I've simply forgotten to place the user object or the computer object into the OU to which I want the GPO to apply. Therefore, the object isn't in the "scope" of where Group Policy will apply.

You can configure all the user or computer policy settings on an OU that you like, but, quite obviously, unless that user or computer object is actually in the OU, the target computer will simply not receive the message you're sending. And, no, you cannot just move a security group that contains the user or computer objects and plunk it in the desired OU. Group Policy doesn't work that way. That actual user or computer object needs to be in the site, domain, or OU that the GPO applies! And since no two objects can be in any two OUs at the same time, this can be a challenge.

Tip 

Security groups are irrelevantexcept for filtering.

Is there a Firewall On (or Between) Your Domain Controllers?

Windows XP/SP2 gets a lot of press because it ships with the firewall turned on. But Windows 2003 (with and without SP1) also has a firewall. It's just that Windows 2003's firewall isn't turned on by default.

So, if your Domain Controllers are Windows 2003, and, someone inadvertently turned on the built-in firewall, your clients will not be able to make contact to then download the Group Policy Objects.

Likewise, if someone has put up a firewall between your client and your Domain Controllers, you simply won't be able to get the Domain Controller's attention, and hence you can't download Group Policy.

Did You Disable ICMP (Ping) from Your Clients to Your Domain Controllers?

Once a client system makes contact with a Domain Controller to download its Group Policy Objects, it then immediately does a quick "speed test" to see whether it's on a fast network or a slow network. It does this by the ICMP protocol, more commonly described as "Ping."

Before we get into what happens when clients cannot ping Domain Controllers, let's first examine why they might not be able to ping Domain Controllers:

• There's a firewall between the client and Domain Controller that prevents ICMP.

• There's a firewall on the Domain Controller itself (such as Windows 2003's firewall that prevents ICMP).

• You have a router between the client and the Domain Controller that doesn't like the size of the ICMP test packets the client is using. Therefore, the ICMP test packets are being discarded, and it's as if they're never reaching the Domain Controller at all. Microsoft has a Knowledge Base article about this specific problem and its resolution at http://tinyurl.com/df9bx .

Let's examine the first two issues (which is really the same thing). That is, what if ICMP simply cannot be passed along to the Domain Controller? Perhaps a corporate decision to squash ICMP packets has been passed down, and now you just have to "handle it."

If ICMP is disabled, then slow link detection is out the window. That is, because the client cannot determine the speed of the connection, a "fast link" is always assumed. With that in mind, be sure to consider the impact when software installation and folder redirection comes into play.

Did Someone Muck with the ACLs of the GPT Part of the GPO in SYSVOL?

There is very, very little reason to ever need to manually dig into the guts of the GPO within SYSVOL (that's the GPT part) and manually manipulate the file ACLs. However, uninitiated administrators will sometimes playto nasty consequences. And, as stated earlier, GPOTOOL /checkacl won't actually validate the file ACLs on the GPO's GPT parts . In other words, if the ACLs on the GPT are damaged, your best bet is to whack the GPO, and restore from backup. The restore process should create the GPO with the correct ACLs upon its recreation.