First:
Event Type: Error
Event Source: SceCli
Event Category: None
Event ID: 1001
Date: 2/9/2004
Time: 8:09:51 PM
User: N/A
Computer: ENT-LT-001
Description:
Security policy cannot be propagated. Cannot delete GP
cache.
Immediately followed by:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 2/9/2004
Time: 8:09:51 PM
User: NT AUTHORITY\SYSTEM
Computer: ENT-LT-001
Description:
The Group Policy client-side extension Security failed to
execute. Please look for any errors reported earlier by
that extension.
Running RSOP.MSC on a client there is a yellow warning indicator on the Computer Configuration and the Error Information shows that the Security Component has a Failed Status with the following:
Monday, February 09, 2004 9:37:55 PM
Security failed due to the error listed below.
The I/O operation has been aborted because of either a
thread exit or an application request.
Additional Information:
Security policy cannot be propagated.
Cannot delete GP cache.
Turning on UserEnvDebugLevel = 0x00010002 the following is
recorded in UserEnv.log:
USERENV(1ec.52c) 21:37:54:457 ProcessGPOList: Entering for extension Security
USERENV(1ec.52c) 21:37:54:457 MachinePolicyCallback: Setting status UI to Applying Security policy...
USERENV(1ec.52c) 21:37:54:477 GetWbemServices: CoCreateInstance succeeded
USERENV(1ec.52c) 21:37:54:787 ConnectToNameSpace: ConnectServer returned 0x0
USERENV(1ec.52c) 21:37:55:128 LogExtSessionStatus: Successfully logged Extension Session data
USERENV(1ec.52c) 21:37:55:208 MachinePolicyCallback: Setting status UI to Applying computer settings...
USERENV(1ec.52c) 21:37:55:208 ProcessGPOList: Extension Security returned 0x3e3.
USERENV(1ec.52c) 21:37:55:208 ProcessGPOList: Extension Security was able to log data. RsopStatus = 0x0, dwRet = 995, Clearing the dirty bit
USERENV(1ec.52c) 21:37:55:228 ProcessGPOs: Extension Security ProcessGroupPolicy failed, status 0x3e3.
In case matters I should say that the Domain Functional Level is Windows 2003, but the Forest Function Level is still at Windows 2000.
I cannot find anything on how to fix or overcome this "Cannot delete GP cache" issue on the XP clients. I have check all over Technet, Microsoft.com and elsewhere on the web. I can't even seem to find anything that even mentions anything about deleting a GP cache!
This 2003 AD domain is vertually the same configuration and GPO configuration I had for a 2000 AD domain and never experienced anything like this.
I would sure appreciate any suggestions because at the moment I cannot add any XP clients to this domain that will get their security settings from the Active Directory GPOs.
Thanks in advance for any help,
Henry Halter
Looks like you have a good one here!
After a quick search, I came up with this article: 827012. This is talking
about a mismatch in where the security template came from. I am guessing it
might be your issue too. maybe you can reconfigure a GPO from the same
version to see if you can get ANY security settings to apply from the
security templates of that same OS?
--
Derek Melber
"Henry Halter" <info....@adelphia.net> wrote in message
news:A3A5B1BF-1F3C-4E15...@microsoft.com...
Thanks for the reply, but I got a reply from a member on the partners newsgroup.
Turns out that the "Cannot delete GP cache" is referring to the files in the the \windows\security\templates\policies folder on the client and they had the read-only attribute set and the client-side security extension could not delete or update them. How they got set that way I outline below in the response I made in that newsgroup:
Hi Hove,
Thanks for the info, and you were right about problem. All the files in the \windows\security\templates\policies were mark as read-only. The root of the problem turns out to be how I originally created the group policies.
I had copied all the security templates from the Win 2003 Security Guide that I had on a CD an put them into the \Windows\security\templates directory on the server and this took along the read-only attribute with the files. So when I created group policies by importing the security templates this copies the templates along with the read-only attribute to the SYSVOL.
Well this left a bunch of the templates in the SYSVOL as read-only. Consequently when the template is brought down to the client so is the read-only attribute. Now you have the security policies on the client with read-only set and they cannot be deleted or updated by the client-side security extension.
So the complete fix was to remove the read-only from the templates in the SYSVOL, delete the all the files from the security policy cache on the client and then run the GPUPDATE /FORCE.
By the way, taking the read-only attribute off files in the SYSVOL was very tricky and combersome, so the word of warning is to make sure NOT to start with security templates that are read-only when importing them into group policies.
Thanks again for the help,
Henry