There's two ways to find out what software restriction policy is up to. First, software restriction policy rules should show events in the Application event log when they are fired. Those events have event IDs between 865 and 868 and show details of what process kicked of which SRP rule. If you need even more detail, you can enable verbose trace logging of SRP by modifying the registry on the system receiving the policy. This is done by creating the following registry key, if it doesn't already exist:

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers

and adding a registry value to that CodeIdentifiers key, of type REG_SZ, called LogFileName. In the LogFileName value, enter a path to a log file name (any path and filename you want). For example, you could enter: c:\logs\srplog.txt in this value and the SRP trace log would be stored in that file.

When security policy is processed, Windows uses the secedit security configuration engine to process Group Policy-based security policy. Part of this processing relies on using a local security database, found on each Windows system, called secedit.sdb. This file is found, by default, in c:\windows\security\database. Occasionally this database can get corrupted and prevent security policy from applying on that machine. You can check for this by running the following command:

esentutl /g c:\windows\security\database\secedit.sdb

If the command finds errors you can use the esentutl utility's /p option to attempt to repair the file.

Yes, in fact security policy is one of those anomalies with respect to the "Don't process if the GPO hasn't changed" rules. By default, security policy (which is defined as policy found in Computer Configuration|Windows Settings|Security Settings) will process every 16 hours in the background, even if the GPO hasn't changed. This ensures that, for a critical area like security configuration, if the user has made a change on the local system that contravenes policy, that change will be undone on a periodic basis. You can actually modify this background refresh interval by editing the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\MaxNoGPOListChangesInterval

This value is stored as a hexadecimal number that represents the number of minutes between background refreshes.

There is a known issue in XP, SP1 and Win2K earlier than SP4 where using this feature in Restricted Group Policy won't work. Check out http://support.microsoft.com/default.aspx?scid=kb;en-us;Q810076 for information on a hotfix for XP. Note that there are two modes of operation for Restricted Groups policy. There's the "Members" policy in the top box, which mandates that, for a given group, only those users/groups listed in this dialog may be members. Use this policy with caution because any members of the target group that aren't in the list get removed the next time the GPO is processed. And administrative groups are excluded from this, meaning that you can very easily lock yourself out of a bunch of machine if you're not careful. The second part of Restricted Groups is the "Members of". This is where you can optionally ensure that the selected group is made of a member of a list of other groups. This membership in the local Administrators group is what was fixed by the hotfix noted above. Note also that if you use Restricted Groups policy on a GPO that is targeted by a Domain Controller, then the groups whose membership you are effecting reside in AD and thus this policy has an impact on AD replication and group membership (esp. in pre-Win2K3 environments where group membership is replicated as a single attribute).