Group Policy not coming down on some machines

Question

Environment:
Client 4.83SP1
Windows 2k SP4
Netware 5.1
eDir 8.7.3
Zen 3.2
Symptom:
After several agonizing days of going through the TIDs and turning on
debugging and checking all file dates on the workstation in question, a
working laptop and the public folders on the servers I've come up with the
following but I don't know the cause:
The workstation in question (and there are sporadic workstations with the
same problem) finds and uses the Container Policy (ZEN3 version) then reads
the User Package but will not execute the binding orders of the Group
Policy. As a matter of fact, I turned on Group Policy logging (TID
10058023) and a file is never created. Also, the Group Policies subkey in
the "HKLM/Software/Novell/Workstation Manager". I turned on ZenPOL32
logging and compared my laptop which is working to the workstation in
question. First, they are not applying the policies in the same order (DLU
is always first, but after that, the order is hap-hazard). But, I also see
some sections that make me wonder why the workstation is giving up. These
files are huges so I'd rather not post in this, but I'll put the pieces that
are raising my eyebrows:
Workstation in Question has the following piece about the Group Policy
Package:
ENTER ZENGetPolicyPackageDN -- tree = EPSD_TREE
ZENGetPolicyPackageDN -- policyDN = CN=Student User
Package:WinNT-2000-XP:Windows Group
Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
Entering DSGetUserContext.
os version = 4
Preferred Tree = EPSD_TREE_______________________
Set Context to Tree = EPSD_TREE
CreateContext = 2
NWDSWhoAmI-2 returned (0) "CN=100341.OU=Students.OU=LMMS.OU=Middle.O=EPS D".
Verify TYPED (0) "CN=100341.OU=Students.OU=LMMS.OU=Middle.O=EPS D".
Preferred Tree = EPSD_TREE_______________________
Set Context to Tree = EPSD_TREE
CreateContext = 2
DSGetObjectAttrVal -- objectName -- CN=Student User
Package:WinNT-2000-XP:Windows Group
Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
DSGetObjectAttrVal -- attrName -- zenpolAssociation
EXIT DSGetObjectAttrVal -- ccode -- 0
ZENGetPolicyPackageDN -- packageDN -- CN=Student User
Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
EXIT ZENGetPolicyPackageDN
The Laptop, in comparison for the same Group Policy Package has the
following:
PACKAGE FOUND = CN=Student User
Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
FindPolicy - objectName = CN=Student User
Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
FindPolicy - attrName = zenpolPolicy attrType = zenwmGroupPolicy
ZENGetObjectAttributes - attrName = zenpolPolicy objName = CN=Student User
Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
Enabled Policy = CN=Student User Package:WinNT-2000-XP:Windows Group
Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
AddStringtoList -- Adding -- CN=Student User Package:WinNT-2000-XP:Windows
Group Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
Enabled Policy(platformSpecific[4]) = CN=Student User
Package:WinNT-2000-XP:Windows Group
Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
IsStringInList -- zenwmGroupPolicy -- is already in the list.
It appears that the workstation in question is having trouble resolving the
Effective policies. The laptop, on the other hand, has no such entries
anywhere in the log about effective policies.
If anyone has ideas I would love it. Uninstalling the 4.83sp1 client and
reisntalling did not help. I've DSREPAIR'd the tree several times with
Rebuild Operational Schema. WHen I uninstalled 4.83sp1 I checked the
registry and the Novell subkey was cleared out.
I'm burnt out on this one. If you want both log files, please post your
email address without the @ symbol and I'll fire them off to you.
Thanks in advance.
Bill Prehl
Network Manager
East Penn School District
prehlb at eastpennsd dot org

Answer 1

Here's the skinny on our situation.
1) We do not let the users update MS patches in our district. We do them
manually (still).
2) We are running the 4.83sp1 client on Win2k (have not got around to
upgrading to 4.90sp2). Our A/V had broke on 4.90 and we had to back it down
last year. So, XP machines are at 4.90sp2.
Win2k machine last had MS patches applied on 7/11/05 - this is a critical
point.
First, I discovered that the Policy Object in the tree was "corrupt" for
some of the 4.83sp1 clients. I'm betting all of them. Because the
zenpol32.dll was "seeing" the group policy objects but it was looking for a
zenpackage = effective in the log file. It was never initiating the
wmgrppol.dll to bring down and implement the group policies. Recreated the
policy object in the tree (not the Group Policies - reused the same folder)
and now the zenpol32.dll was operating properly but, still not getting the
NAL as the desktop. But, now the windows desktop was locking down but late,
very late. I would get the desktop and click on START and see the entire
start menu. Wait 10 seconds and secedit kicked in and now I had a
locked-down START menu.
Second, secedit appeared to be very delayed or wmgrppol.dll was having
trouble. I noticed this machine required 7 critical patches (one is the
genuine tool so really six patches). The last time patches were applied was
on 7/11/05. I noticed also that when I wanted to turn on secedit logging
(gpextensions registry keys) that even after a reboot there was no log file.
Apply the critical patches and now the NAL immediately works as the desktop
shell.
I worked on this problem for and entire work week plus some after hours
work.
Side note: Our XP machines with the 4.90sp2 client did not have a problem
seeing the Group Policy package in the tree. Only the 4.83sp1 client. So,
recreating the policy in the tree only helped the 4.83sp1 clients. Also, I
don't believe MS broke secedit in XP because they changed it to gpupdate.exe
so I'm betting it's a different configuration and the patches that broke
Win2k did not get applied to XP.
There is nothing on MS site that I could find about this nor does Novell
seem aware (or even care since it's 4.83sp1 and Zen3.2sp1). Maybe this post
will save somebody a lot of headache. If they keep MS patches up to date
they probably will never notice this problem unless they hit it over the
summer after MS released the secedit patch that broke it.
Cheers.
Bill Prehl
"Bill Prehl" <[email protected]> wrote in message
news:[email protected]...
> Environment:
> Client 4.83SP1
> Windows 2k SP4
> Netware 5.1
> eDir 8.7.3
> Zen 3.2
>
> Symptom:
> After several agonizing days of going through the TIDs and turning on
> debugging and checking all file dates on the workstation in question, a
> working laptop and the public folders on the servers I've come up with the
> following but I don't know the cause:
>
> The workstation in question (and there are sporadic workstations with the
> same problem) finds and uses the Container Policy (ZEN3 version) then
reads
> the User Package but will not execute the binding orders of the Group
> Policy. As a matter of fact, I turned on Group Policy logging (TID
> 10058023) and a file is never created. Also, the Group Policies subkey in
> the "HKLM/Software/Novell/Workstation Manager". I turned on ZenPOL32
> logging and compared my laptop which is working to the workstation in
> question. First, they are not applying the policies in the same order
(DLU
> is always first, but after that, the order is hap-hazard). But, I also
see
> some sections that make me wonder why the workstation is giving up. These
> files are huges so I'd rather not post in this, but I'll put the pieces
that
> are raising my eyebrows:
>
> Workstation in Question has the following piece about the Group Policy
> Package:
>
> *********
> ENTER ZENGetPolicyPackageDN -- tree = EPSD_TREE
> ZENGetPolicyPackageDN -- policyDN = CN=Student User
> Package:WinNT-2000-XP:Windows Group
> Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
> Entering DSGetUserContext.
> os version = 4
> Preferred Tree = EPSD_TREE_______________________
> Set Context to Tree = EPSD_TREE
> CreateContext = 2
> NWDSWhoAmI-2 returned (0)
"CN=100341.OU=Students.OU=LMMS.OU=Middle.O=EPS D".
> Verify TYPED (0) "CN=100341.OU=Students.OU=LMMS.OU=Middle.O=EPS D".
> Preferred Tree = EPSD_TREE_______________________
> Set Context to Tree = EPSD_TREE
> CreateContext = 2
> DSGetObjectAttrVal -- objectName -- CN=Student User
> Package:WinNT-2000-XP:Windows Group
> Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
> DSGetObjectAttrVal -- attrName -- zenpolAssociation
> EXIT DSGetObjectAttrVal -- ccode -- 0
> ZENGetPolicyPackageDN -- packageDN -- CN=Student User
> Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
> EXIT ZENGetPolicyPackageDN
>
> *********
>
> The Laptop, in comparison for the same Group Policy Package has the
> following:
>
> *********
> PACKAGE FOUND = CN=Student User
> Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
> FindPolicy - objectName = CN=Student User
> Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
> FindPolicy - attrName = zenpolPolicy attrType = zenwmGroupPolicy
> ZENGetObjectAttributes - attrName = zenpolPolicy objName = CN=Student User
> Package.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EP SD
> Enabled Policy = CN=Student User Package:WinNT-2000-XP:Windows Group
> Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
> AddStringtoList -- Adding -- CN=Student User Package:WinNT-2000-XP:Windows
> Group Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
> Enabled Policy(platformSpecific[4]) = CN=Student User
> Package:WinNT-2000-XP:Windows Group
> Policy.OU=ZFD3.OU=Policies.OU=LMMS.OU=Middle.O=EPS D
> IsStringInList -- zenwmGroupPolicy -- is already in the list.
>
> *********
>
> It appears that the workstation in question is having trouble resolving
the
> Effective policies. The laptop, on the other hand, has no such entries
> anywhere in the log about effective policies.
>
> If anyone has ideas I would love it. Uninstalling the 4.83sp1 client and
> reisntalling did not help. I've DSREPAIR'd the tree several times with
> Rebuild Operational Schema. WHen I uninstalled 4.83sp1 I checked the
> registry and the Novell subkey was cleared out.
>
> I'm burnt out on this one. If you want both log files, please post your
> email address without the @ symbol and I'll fire them off to you.
>
> Thanks in advance.
>
> Bill Prehl
> Network Manager
> East Penn School District
> prehlb at eastpennsd dot org
>
>