Windows – Group policy central store replication

What is Group Policy?

Group Policy is a tool that is available to administrators that are running a Windows 2000 or later Active Directory Domain. It allows for centralized management of settings on client computers and servers joined to the domain as well as providing a rudimentary way to distribute software.

Settings are grouped into objects called Group Policy Objects (GPOs). GPOs are linked to an Active Directory organizational unit (OU) and can be applied to users and computers. GPOs cannot be applied to groups directly, though you can use security filtering or item-level targeting to filter policy application based on group membership.

That's cool, what can it do?

Anything.

Seriously, you can do anything that you want to users or computers in your domain. There are hundreds of pre-defined settings for things like folder redirection, password complexity, power settings, drive mappings, drive encryption, Windows Update, and so on. Anything that you can't configure via a pre-defined setting you can control via scripting. Batch and VBScript scripts are supported on all supported clients and PowerShell scripts can be run on Windows 7 hosts.

Professional tip: You can actually run PowerShell startup scripts on Windows XP and Windows Vista hosts as well as long as they have PowerShell 2.0 installed. You can make a batch file that calls the script with this syntax:

powershell Set-ExecutionPolicy RemoteSigned
powershell \\\\server\share\script.ps1
powershell Set-ExecutionPolicy Restricted

The first line allows unsigned scripts from remote shares to be run on that host and the second line calls the script from the batch file. The third line sets sets the policy back to restricted (the default) for maximum security.

How are Group Policy Objects applied?

GPOs are applied in a predictable order. Local policies are applied first. There are policies set on the local machine via gpedit.msc. Site policies are applied second. Domain policies are applied third, and OU policies are applied fourth. If an object is nested inside of multiple OUs, then the GPOs are applied at the OUs closest to the root first.

Keep in mind that if there is a conflict, the last GPO applied "wins." This means, for example, that the policy linked at the OU that a computer resides in will win if there is a conflict between a setting in that GPO and one linked in a parent OU.

Logon and Startup Scripts seem cool, how do those work?

A logon or startup script can live on any network share as long as the Domain Users and Domain Computers groups have read access to the share that they are on. Traditionally, they reside in \\domain.tld\sysvol, but that's not a requirement.

Startup scripts are run when the computer starts up. They are run as the SYSTEM account on the local machine. This means that they access network resources as the computer's account. For example, if you wanted a startup script to have access to a network resource on a share that has the UNC of \\server01\share1 and the computer's name was WORKSTATION01 you would need to make sure that WORKSTATION01$ had access to that share. Since this script is run as system, it can do stuff like install software, modify privileged sections of the registry, and modify most files on the local machine.

Logon scripts are run in the security context of the locally logged on user. Hopefully your users aren't administrators, so that means that you won't be able to use these to install software or modify protected registry settings.

Logon and startup scripts were a cornerstone of Windows 2003 and earlier domains, but their usefulness has been diminished in later releases of Windows Server. Group Policy Preferences gives administrators a much better way to handle drive and printer mappings, shortcuts, files, registry entries, local group membership and many other things that could only be done in a startup or logon script. If you're thinking that you might need to use a script for a simple task, there's probably a Group Policy or preference for it instead. Nowadays on domains with Windows 7 (or later) clients, only complex tasks require startup or logon scripts.

I found a cool GPO, but it applies to users, I want it to apply to computers!

Yeah, I know. I've been there. This is especially prevalent in academic lab or other shared computer scenarios where you want some of the user policies for printers or similar resources to be based on the computer, not the user. Guess what, you're in luck! You want to enable the GPO setting for Group Policy Loopback Mode.

You're welcome.

You said I can use this to install software, right?

Yep, you can. There are some caveats, though. The software must be in MSI format, and any modifications to it must be in an MST file. You can make an MST with software like ORCA or any other MSI editor. If you don't make a transform, your end result will be the same as running msiexec /i <path to software> /q

The software is also only installed at startup, so it's not a very fast way of distributing software, but it's free. In a low-budget lab environment, I've made a scheduled task (via GPO) that will reboot every lab computer at midnight with a random 30 minute offset. This will ensure that software is, at a maximum, one day out of date in those labs. Still, software like SCCM, LANDesk, Altaris, or anything else that can "push" software on an on-demand basis is preferable.

How often is it applied?

Clients refresh their Group Policy Objects every 90 minutes with a 30 minute randomization. That means that, by default, there can be up to a 120 minute wait. Also, some settings, like drive mappings, folder redirection, and file preferences, are only applied on startup or logon. Group Policy is meant for long-term planned management, not for instant quick-fix situations.

Domain Controllers refresh their policy every five minutes.

To put the new ADMX files into your Central Store, you most likely created a folder similar to

\\domain.example.com\SYSVOL\domain.example.com\Policies\PolicyDefinitions

Then, you placed the .admx files inside it.

The existence of the Policies folder is not an indicator of a previously existing Central Store. By creating the PolicyDefinitions you've basically created said Central Store.

When no Central Store exists, the group policy management console will display the group policy templates that are stored locally on the machine. These can be found in %systemroot%\PolicyDefinitions.

Once a Central Store exists, group policy templates will be loaded exclusively from there, the local policy templates are ignored.

You can now either load them manually when editing a group policy object (Right-click Administrative Templates, Add/remove templates, select the .admx files from %systemroot%\PolicyDefinitions), or simply populate your Central Store with the local templates:

1. Open a command window: click Start, click Run, then type cmd.

2. To copy all the language-neutral ADMX files from your Windows Vista administrative workstation to the central store on your domain controller using the xcopy command, type:

    xcopy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\
   

3. To copy all ADMX language resource files from your Windows Vista administrative workstation to the central store on your domain controller using the xcopy command, type:

    xcopy %systemroot%\PolicyDefinitions\EN-US\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\EN-US\