Problems evaluating group policies

Problem:

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

Solution:

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.intranet' domain, for example, the client must be able to access the network path //univention.intranet/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:

C:\ gpupdate /force

Make sure no gateway is set for a nameserver in the Windows but just domain controllers.
You also can do some checks on you windows client:
Check the logonserver:

C:\ set log

lists the domain controllers (DCs) in domain ‘schein.ig’

C:\ nltest /dclist:schein.ig

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

7. Missing referenced GPOs in sysvol

It might happen that a GPO is referenced in LDAP/AD bit doesn’t exist on the sysvol. This can have plenty of reasons.

  1. The GPO folder has been deleted but is still referenced.
    In this case you need to recreate the policy.
  2. The GPO folder does not exist on a specific DC that happened to be accessed in this case.
    Check the sysvol.log for any reason why the GPO had not been synced. This might be as permission problem.

8. Revision mismatch between LDAP and GPT.ini

You might check the Revision like

root@ucs:~# grep Version /var/lib/samba/sysvol/$(dnsdomainname)/Policies/*/GPT.INI
/var/lib/samba/sysvol/domain.tld/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/GPT.INI:Version=0
/var/lib/samba/sysvol/domain.tld/Policies/{6AC1786C-016F-11D2-945F-00C04FB984F9}/GPT.INI:Version=0


root@ucs:~# univention-ldapsearch -LLLo ldif-wrap=no "univentionObjectType=container/msgpo" cn msGPOVersionNumber
dn: cn={31B2F340-016D-11D2-945F-00C04FB984F9},cn=Policies,cn=System,dc=domain,dc=tld
cn: {31B2F340-016D-11D2-945F-00C04FB984F9}
msGPOVersionNumber: 0

dn: cn={6AC1786C-016F-11D2-945F-00C04FB984F9},cn=Policies,cn=System,dc=domain,dc=tld
cn: {6AC1786C-016F-11D2-945F-00C04FB984F9}
msGPOVersionNumber: 0