Troubleshooting process for Group Policies not working

  • 3204554
  • 19-Sep-2007
  • 30-Apr-2012

Environment

Novell ZENworks 6.5 Desktop Management Support Pack 2 - ZDM6.5 SP2
Novell ZENworks 7 Desktop Management Support Pack 1 - ZDM7 SP1
Novell Client 4.xx for Windows NT/2000/XP

Situation

How did you create the Group Policies?
Does the setting work during administration?
Is the policy configured correctly?
The Impersonation on the Group Policy should not be changed.
What does the zenwmGroupPolicyPath say in DSBROWSE?
Are the right directories and files present on the server?
Do you have rights to the directory on the server?
Are the same directories and files present on the workstation?
Is the wmgrppol.dll in the PreDesktopHelperDLLs regkey?
Do you see the policy in the scheduler?
Does the .UserCache and .WksCache get created?
What happens if you delete the local Group Policy directories?
Does secedit /refreshpolicy or gpupdate work?
What happens if you delete the regkey entry for GroupPolicies?
What does the Group Policy debug log say?
What does the trace say?
Troubleshooting process for Group Policies not working

Resolution

Group Policy administration needs to be performed on a workstation with the same OS as the OS you are trying to administer. The only exception to this rule is that you can administrate on an XP workstation when configuring policies for the 2000 OS. Additionally, if using Windows XP for administration, the newer WMPOLICIES.JAR and WMPOLICIESR.JAR files must be in the ConsoleOne\1.2\snapins\zen directory. These can be found in the latest zfd3.2 patches.
During administration of Group Policies, the administrators current group policy is copied to a gptmpxxx directory and then his live policy is configured. When exiting the MMC, the live policy is copied to and then the administrator’s original policy is copied from the gptmpxxx directory back to his GroupPolicy directory.

However, during administration, since the admin’s live group policy is being edited, you can test your setting while administrating. For example, if you set the setting Disable the Start, Run option, then test it before exiting the MMC by looking at your Start Menu.
Group Policies exist in both the User and the Workstation Policy Packages. Both have the ability to push down User, Computer, and Security settings. However, to push them down, the checkbox must be checked. So, for troubleshooting purposes, one should ensure that the setting set within the MMC correlate with the settings being pushed down (User, Computer, Security).

Additionally, the workstation policy package has the ability to perform loopback support. This means that the Workstation Package settings can either take precedence over the User Package settings, or ignore the User Package settings, or be overwritten by the User Package settings. The default is for the User Package to have precedence over the User Package settings. These settings need to be confirmed that they are correct according to what the customer wishes are.
Group Policies under a user package need to have an impersonation of "Interactive User". When delivering the policy, the impersonation is read and key flags are set in the registry. If the impersonation gets changed, then the flags will be set incorrectly and the policy will not apply.

To access the Impersonation for a Group Policy, hightlight the Policy in a User Package, and choose "Edit". In the dialog that comes up, choose "Advanced Settings" which will bring up another dialog. Select the "Impersonation" tab, then set the impersonation to "Interactive User" on a User Package.

In the Group Policy log file will be a line like the following:

WMHelperInitialization (Jul 18 2003) called! Flags: 0x2002. Event: 0x2000. Impersonation: 0x2

The Flags: 0x2002 is for System Impersonation and should only be set for Workstation Group Policies. User Group Policies should have the setting of Flags: 0x2001.
The attribute read during group policy implementation is the zenwmGroupPolicyPath. If this is pointing to a bogus path, then the user will not bring down the policy and no settings will be in effect. Verify the path in this attribute on all the servers that hold a copy of the partition holding the Policy Package.
When troubleshooting the Group Policies coming down to the workstation, it is always good to find out where in the process it broke. After editing Group Policies from within ConsoleOne, a certain directory structure is created in the path specified on the server. Go check this path to ensure the right directories exist. The following should be there:

Adm - This directory should hold the ADMs that the MMC used to administrate the policy with. By default, the conf.adm, inetres.adm, and the system.adm are put in here. Others will be in here also if the administrator has added them.

Machine & User - These directories are created by default and will hold inside of them the .POL files for modified settings. For example, let’s say the administrator disabled the users ability to Add Printers. Well, since this setting is underneath the User Configuration\Control Panel\Printers structure in the MMC, then there will be a registry.pol file that has that registry key in it (the one to disable the addition of printers). Also, any scripts that are referenced inside the group policies will usually be kept in these folders.

gpt.ini - This file will also be present at the root of the specified directory location. This file is used by Microsoft when applying the group policy settings.
In order for the group policy to apply on a given workstation, the appropriate rights are necessary to copy the policy down. If the policy is in a User Package, the user objects will need the rights to bring down the directory structure. If the policy is in a Workstation Package, then the workstation object must have the necessary file system rights to retrieve the directory structure. When troubleshooting, you can test the User Package out by manually copying from the server to the workstation.
The policy apply process will only tell Microsoft to apply what is currently in the \system32\grouppolicy directory. To ensure that the correct directories and files are there, compare the structure against the structure contained in the specified path on the server (defined in the policy).
In order for Group Policies to get applied before the desktop is built, the StringValue WMGRPPOL.DLL must exist in the PredesktopHelperDLLs key underneath HKLM\Software\Novell\Workstation Manager.
When double-clicking on the Novell Desktop Management icon in the systray (or if that is disabled, just type WMSCHED from Start, Run), is the User and/or Workstation Group Policy in there? Since both are schedulable policies, they should show up in here. If not, it is time to troubleshoot ZENPOL32 policy retrieval (look at Search Policies, Workstation Manager, Trusted Tree settings, etc). If they are in there, what are the scheduled times for running? If left at the Package default, the policies may not get applied when the administrator wants them to.
When Group Policies apply on the workstation, the original user settings and the original workstation settings are saved off in separate cache directories. This is so settings can be returned to some normality if part of the process fails, and also if the User Policy Package is NOT set to remain in effect on user logout, then these settings are restored on logout.
If you delete the c:\\system32\GroupPolicy, GroupPolicy.UserCache, & GroupPolicy.WksCache directories and then try to process Group Policies again, what is the result? If they work now, then possibly some corrupt policy existed locally.
If you manually copy down the directories from the specified path on the server, place them in the c:\\system32\GroupPolicy directory, and then refresh the policies, does it work? Specifically, to refresh policies on Windows 2000, you’ll use the following command from Start, Run:

secedit /refreshpolicy [use machine_policy or user_policy] /enforce

If you are on Windows XP, then use the following command from Start, Run:

gpupdate /[use computer or user] /force

If this doesn’t work, then you’ve isolated the problem to be something other than ZENworks. If it does work, then we need to look at the helper
Group Policies will only be brought down from the network again if something has changed since the last time we read the policy. To force the group policy to come down again, you could delete the registry entry that lets WMGRPPOL.DLL know that he’s processed this policy previously. That entry is:

HKLM\Software\Novell\Workstation Manager\Group Policies\Workstation OR User
To enable the extra debug logging for Group Policies, just define a path in the registry for the location you want the log file to be written to. This is under HKLM\Software\Novell\Workstation Manager\Group Policies and the StringValue named Log Path should be set to some path and filename.
The best trace to get when troubleshooting Group Policies is every packet to and from the workstation while booting up and through the login process until the desktop is active.

Additional Information

Notes:

1. It is recommended that a default or base Group Policy set (with or without any settings changed) be delivered to workstations to have a 'known' configuration to start with. The delivery of the default or base GP set can be with the w/s image, but could also be via a Group Policy. Deleting the \%windir%\system32\grouppolicy folder(s) does not reset all Group Policies back to 'default'. It does some, but not all. If no \grouppolicy folder exists, loading GPEDIT will create a initial Group Policy set and that GP set can be used if that initial set is what is desired for a default or base set. It is proper testing to test GP changes to workstations that have never had any changes done but have the default or base GP set.

2. Remember, when making changes to and setting up Group Policies via C1, the GP copy process to the target location is copying the existing GP set and the changes to the target location. Testing the delivery of those same policies should be to another w/s that have not had those changes made. Also, rebooting the test box twice is a good practice as policies may take two boots to be delivered and applied.

3. Some Group Policies (Ex: GPEDIT, Local Computer Policy, Computer Configuration, Administrative Templates, Network, Network Connections, Windows Firewall, Standard Profile--ones with sub-configuration) created with C1 (1.3.6c) with ZDF 4.0.1 IR7 snapins on a XP SP 2 workstation for delivery to XP SP2 ZFD 4.0.1 IR7 ZFDAGENTS do not successfully apply. If those same Group Policies are created with ZDM 6.5 SP2 or 7 snapins and delivered to a ZFD 4.0.1 IR 7 ZFDAGENT, they do apply. This is a recently identified 'known' issue that will not be fixed.

Formerly known as TID# 10073744