Group Policy's power is well known.
But just as well known are the
annoying things about it, when it doesn't always work the way you'd expect.
Equally frustrating, the myriad of different
capabilities that Group Policy brings—literally
thousands of settings—make it tough to know
when you can use this technology for a given
problem. I've helped many people get the most
from Group Policy, and frequently I've seen
the same few annoyances cause more than
their share of problems. Here's what you can
do about them.
Policy Settings Don't Take
Effect Immediately
Sometimes it takes two to three reboots for
a particular policy setting to take effect. This
behavior can be disconcerting because you're
not sure whether or not the setting is working.
It happens most often for Folder Redirection
or Software Installation Group Policy Objects
(GPOs), primarily on Windows XP.
This delay is caused by an XP feature called
Fast Logon Optimization. In the interests of
getting an XP system booted and the user
logged on as fast as possible, Microsoft enabled
what's referred to as asynchronous foreground Group Policy processing by default. Essentially
what this means is that while the computer is
starting up, computer-specific Group Policy
processing occurs at the same time that the
system is working on presenting the logon dialog box to the user. In fact, computer-specific
Group Policy processing might still be running
when the user enters a username and password and starts to log on. Similarly, when the
user logs on, user-specific Group Policy processing starts running and might still be running when the desktop appears. Certain GPO
settings—Folder Redirection and Software
Installation, for example—need "exclusive"
access to the computer or user environment
to run. In other words, they need to run synchronously, rather than asynchronously. The
Group Policy processing needs to finish doing
its thing before the system presents the user
with a logon dialog box or the desktop. So how
do we tell XP to process GPOs synchronously?
By using a policy setting, of course!
Open Group Policy Editor (GPE) and
expand Computer Configuration\Administrative Templates\System\Logon to see a policy
called Always wait for the network at computer startup and logon. Enable this policy
for your XP computers, and they'll always run
foreground Group Policy processing synchronously. You'll increase the time it takes for a
user to boot up a machine and get logged on,
but you'll also eliminate the multiple reboot or
logon problem when trying to deliver certain
kinds of policy. Windows Vista is set to asynchronous processing, just like XP; however,
Windows 2000 is set by default to synchronous
foreground processing.
Policy Settings Don't Take
Effect at All
Sometimes a Group Policy setting doesn't
apply at all, and I see 1058 and 1030 event log
errors in the Application event log on the client that's having problems. The errors seem to
indicate that the system can't read the gpt.ini
file. This is a common problem, unfortunately.
Because many problems could cause these
errors, the best solution is to narrow down the
possible causes.
If you notice that this problem occurs only for
computer policy settings and not for user policy
settings, the cause could be a network-stack
timing problem—the computer is booting so
quickly that the network stack hasn't had time
to initialize fully before the system attempts
Group Policy processing, so computer-policy
processing fails. However, by the time the user is ready to log on, the stack is up and running, so
user-policy processing works just fine.
Microsoft added a nifty little registry entry
to certain versions of Windows, which you can
use to tell the system to wait until the network
stack is finished initializing before Windows
starts policy processing. This registry entry
is described in the Microsoft article "Group
Policy application fails on a computer that is
running Windows 2000, Windows XP Service
Pack 1, or Windows XP Service Pack 2" (http://support.microsoft.com/?kbid=840669). You'll
also find it as a GPO setting in Windows Vista,
under Computer Configuration\Administrative Templates\System\Group Policy\Startup
policy processing wait time.
Other problems might cause these error
messages. For example, perhaps the gpt.ini file
really is inaccessible. This file is stored in the
part of a GPO stored in the SYSVOL share on
each domain controller (DC) in your environment. When the system performs either computer- or user-specific Group Policy processing,
it needs to read this file to get information
about the GPO. If the file isn't present on the
DC the system is reading from, Group Policy
processing will fail. You can verify which DC is
servicing Group Policy processing by looking
in the HKEY_LOCAL_MACHINE\SOFTWARE
\Microsoft\Windows\CurrentVersion\Group
Policy\History\DCName registry value.
After you identify the DC in question, verify
that SYSVOL is actually shared out, that the
DFS service is running on the DC (SYSVOL
uses DFS replication), and that the TCP/IP
NetBIOS Helper Service is running on the
client (the client uses this service to communicate with DFS). From a command shell on
the client, you can type
net view \\<DCname
to verify that SYSVOL is shared, and use the
netstart command to verify that all required
services are running. Also browse to the file
location that showed up as inaccessible in the
event log entry and verify that the file is actually there and that the file's permissions are
the same as on another DC where you know
policy is working.
For permission problems, Group Policy
Management Console (GPMC) might be able
to help. Open GPMC focused on the DC that's
having a problem. To do this, change GPMC's
DC focus by right-clicking the domain name
and selecting Change Domain Controller, as
Figure 1 shows. After you've focused GPMC
on the problem DC, go to the Group Policy
Objects container and select the GPO that's
having problems. If GPMC spots permission
problems on that GPO, GPMC will prompt you
and offer to fix them.
Loopback Policy Is
Confusing to Implement
If you're working in the Terminal Server component of the Windows Server 2003 environment, you want to be able to deliver different
policy settings to users when they log on to
the terminal server versus when they log on
to their desktops or laptops. This scenario is
exactly why loopback policy was created, but
the policy can be confusing to implement.
Previous
Register
