Novell ZENworks 7 Desktop Management Support Pack 1 - ZDM7 SP1
Novell Client 4.xx for Windows NT/2000/XP
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
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
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).
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:
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
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:\
If you manually copy down the directories from the specified path on the server, place them in the c:\
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:
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.
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