Problems evaluating group policies




The evaluation of group policies on a Windows client is not functioning correctly.


Problems in the evaluation of group policies can have different causes:

#####1. Incorrect DNS configuration / DNS entries
The Windows client should use a UCS domain controller as its DNS server. No servers which no longer exist or which are currently shut down should be defined in the DNS record of the domain and in the DNS SRV records. This can be checked as follows:

 host $(dnsdomainname)
host -al $(dnsdomainname) | grep " SRV "

When executing the group policies, the Windows client accesses the SYSVOL share of the domain. In a “univention.local” domain, for example, the client must be able to access the network path //univention.local/sysvol reliably.
#####2. Incorrect time setting on Windows client
The Windows client should display the same time as is set on the UCS domain controllers. Attention should also be paid to the time zone.

#####3. Problems with periodic execution of group policies
The evaluation of group policies should be checked directly on the Windows client by entering the following command line in the Windows command line (Windows button + R cmd) and running it by pressing the Enter button:

gpupdate /force

#####4. Evaluation time of machine-related policies
Policies which influence the login procedure of Windows clients often only have an effect on the login service if they are already correctly defined on the server side when the Windows client is started up and can be evaluated by the client. The time should be checked on the Windows client and the Windows client restarted.

#####5. Persistent error messages concerning inconsistent GPO permissions
If an error message appears when the group policy management console (GPMC) is started under Microsoft Windows which indicates inconsistent permissions of GPO files in the SYSVOL share and offers to correct this issue, it should be accepted. In addition, the permissions can be corrected on the UCS domain controllers with the following command:

samba-tool ntacl sysvolreset

To ensure that GPOs and ACLs are in a clean state on all Samba 4 Domain Controllers, the “Sysvol-Sync” can forced to do a complete resync of all data within the sysvol directory:

# Disable Sysvol-Sync on ALL Samba 4 Domain Controllers:
ucr set samba4/sysvol/sync/cron=""

# Remove Sysvol and sync-cache on all Samba 4 Domain Controllers EXCEPT the DC-Master:
cp -a /var/cache/univention-samba4/sysvol-sync /var/cache/univention-samba4/sysvol-sync_bak
cp -a /var/lib/samba/sysvol /var/lib/samba/sysvol_bak
rm -rf /var/cache/univention-samba4/sysvol-sync/*
rm -rf /var/lib/samba/sysvol/*

# Reset sysvol ACLs on the DC-Master
samba-tool ntacl sysvolreset

# Reactivate Sysvol-Sync in ALL Samba 4 Domain Controllers:
ucr set samba4/sysvol/sync/cron="*/5 * * * *" 

#####6. Temporary error messages concerning inconsistencies of the GPOs

The SYSVOL share on the server side is synchronised periodically by the Samba/AD domain controller. In the standard setting, the UCS Samba/AD domain controllers of the UCS server role slave copy the SYSVOL data from another UCS Samba/AD domain controller every 5 minutes without overwriting files which are newer locally. The synchronisation partner subsequently responds to this copying procedure. If group policies are adjusted using administrative tools, there is thus a short phase in which the Windows clients may not yet find the group policy objects in a consistent form and may reject the evaluation until such time as the data found in the SYSVOL of the domain are synchronised again with those in the directory service of the Samba/AD Domain Service (Samba/AD AS).

Should these points not be successful, the debug level of the Samba service can be increased and the log output checked for further errors:

ucr set samba/debug/level=4
/etc/init.d/samba4 restart
less /var/log/samba/log.samba