In this video I will look at what can delay Group Policy settings from taking effect on
your clients and what you can do to speed up the process and get more consistent results.
First I will look at the process that occurs when you make changes to Group Policy. Once
the changes are made these will need to be replicated. I will then look at how to force
a replication if you do not want to wait. There are also some settings that I will look
at which you can configure to speed up the process and give you a more consistent result.
Lastly I will look at forcing Group Policy to update by using the GPUpDate command. Using
GPUpDate allows you to provide Group Policy on a client immediately rather than waiting
for the next refresh. When you make changes to Group Policy by default,
the Group Policy Management Console will attempt to make the changes on the Domain Controller
holding the PDC emulator operational master role. The administrator however can change
this and make the changes on any Domain Controller they wish.
If I open Group Policy Management Console from the start menu, in order to change the
Domain Controller that changes are being made on, all I will need to do is right click the
domain and select the option, “Change Domain Controller.”
You will notice that the option, “The domain controller with the Operations Master token
for the PDC emulator” is ticked by default. While this option is ticked, changes will
be made on the Domain Controller, with the PDC emulator operational master role if it
is available. If there is a slow link between you and the
PDC emulator, you may want to choose the second option, “Any available domain controller.”
This will cause the Group Policy Management Console to attempt to connect to an available
Domain Controller in your site, rather than going across a slow link to connect to the
PDC emulator. The only concern when making changes from different Domain Controllers
is that if two changes were made at different locations there would be a replication conflict
when replication occurred next. When this occurs, Active Directory uses the most recent
change and discards the previous change. The next option, “Any available domain controller
running Windows Server 2003 or later,” will use a Windows Server 2003 Domain Controller
rather than a low level Domain Controller. If you are using a mixed environment this
is a good option to tick. Making Group Policy changes from a new client like Windows 7 to
an old client like Windows Server 2000 can result in some unexpected results and are
best to be avoided if possible. The last option lets you choose which Domain
Controller you want to make the changes on. Regardless of which Domain Controller the
changes are being made on, these changes need to be replicated to the Domain Controller
that the client is authenticating off, for the changes to take effect.
In order for the new Group Policy to be available on the client, replication needs to occur
for the Active Directory database and also the SysVol share. These are replicated using
two different systems. If you want to push Group Policy changes out quickly you can force
a replication of these two different systems. If I want to force a replication of the Active
Directory database I can do this by opening Active Directory Sites and Services from the
start menu. To force a replication, expand down to the server that you want to force
the replication from and go into the NTDS Settings folder. From here, it is matter of
selecting the connection or connections that you want to force a replication on, right
clicking and then selecting the option, “Replicate now.”
You will notice that a dialog box will appear informing you that replication has been triggered
but you will need to use other tools to verify that the replication was successful. The same
result can be achieved from the command prompt. If I close Active Directory Sites and Services,
I can then open a command prompt from the start menu.
To force a replication from this Domain Controller to all its replication partners; run the command
RepAdmin with the parameter /SyncAll. In some cases you may have problems with synchronization
between your Domain Controllers. To check for problems, you can run the command DCDiag.
You can see that even though the last command ran without any errors, when DCDiag was run
some errors have been found. In this case the RPC server is unavailable and there have
been 82 failures since the last replication. This problem is most likely because the server
is not on or not contactable over the network. It is a good idea to check for replication
problems using tools like these or to look in the Event Viewer. If replication is not
working then your clients are not getting Group Policy updates.
The next part of Group Policy replications are the files contained in the SysVol folder.
If you are using FRS to replicate SYSVol you can use the NTFRSUtl command. To force a replication,
enter in the local computer name followed by the /r and then the set name. The Set name
in this case will be, “Domain System Volume SysVol Share.” The last parameter is /p
followed by the DNS name of the Domain Controller that you want to replicate with.
If you are using DFSR to replicate the SYSVol share you will need to use the DFSRDiag command.
The first parameter is SyncNow to indicate that a sync is to be performed. The next parameter
is /Partner colon followed by the computer name you want to sync with.
The next parameter /RGName indicates which data you want to sync. In this case I will
enter in Colon Domain System Volume for the SysVol folder. The last parameter /time indicates
how long to ignore the current replication schedule. In this example I have used
15 minutes. If the replication is not done in 15 minutes it will revert to the current
replication schedule. Once Group Policy replication has occurred,
there are some other issues which may prevent Group Policy from being applied. As we know
from previous videos, Group Policy is applied when the computer starts up and when the user
logs in. When a computer starts up it may apply Group Policy before the networking has
had a chance to start up and download the changed Group Policy.
The end result is the user will login with an old version of Group Policy. When a Group
Policy refresh occurs, the new Group Policy will be applied. However, if changes can only
be performed at start up, the computer will need to be restarted before changes can take
affect meaning two restarts need to be done. In a business environment it is common for
the administrator to want to have changes in Group Policy to happen in a more predictable
way. To do this, you can configure the following Group Policy settings. These settings effectively
force the computer to wait for the networking to start before applying Group Policy. This
gives the computer time to download and update Group Policy before applying it.
Lastly, if you have made any changes to group membership, these changes will also need to
replicate. If you use groups to filter group Policy, if the change to Group memberships
have not replicated these, it can effect who the Group Policy is applied to.
Once Group Policy has updated, the computer will perform a refresh at certain intervals
to check for changes. By default this will occur between 90 and 120 minutes. If you want
to change this you can change it at the following location. There is one setting for regular
computers and another setting for Domain Controllers. In the Group Policy setting you have the option
to add a random offset. Without a random offset, if all your client computers start up at the
same time, they will attempt to update Group Policy at the same time, which could potentially
cause performance problems on your network. If you consider the default settings, the
Group Policy refresh is configured to 90 minutes with a random offset of 30 minutes. This is
why the refresh happens between 90 and 120 minutes.
If you want a refresh to happen straight away, you can run the command GPUpDate. Running
GPUpDate by itself will trigger a background refresh of Group Policy. GPUpdate by itself
will only apply settings that have changed. If you want to ensure that all setting are
applied regardless of whether they have changed or not, add /Force parameter to the command.
The force parameter will reapply all Group Policy settings even if they have not changed.
If you only want to apply user or computer configuration, you can add /Target followed
by user or computer. If you are making changes only to one, this will reduce how long you
will have to wait to see the effects of the changes.
In some case the changes may require a logoff or reboot. GPUpDate will prompt you when this
occurs, however if you want Group Policy to automatically log off the user or reboot the
computer you can add either the /Logoff or /Boot parameter. You can see that when you
are making a lot of changes in Group Policy, GPUpDate is a useful tool to speed up the
process. Thanks for watching this free video from ITFreeTraining.
For the latest video for this course and any others please feel free to subscribe. See
you next time.