locked
GPO not applying to Windows 7 RRS feed

  • Question

  • We are having some issues with GPOs not applying to our Windows 7 Enterprise clients (it works fine on our XP clients).  In particular, the GPO that resets the Local Admin password is not applying.  I'll post the Event Log errors below in hopes that they may mean more to someone else, but the errors seem pretty generic. For the record, we have a separate policy that Renames the local Administrator account on the PCs.  That policy is functioning normally, and is ordered well before the change password policy.    I've been looking at this for a couple of days, and while I can find an error message, I cannot seem to find out what the messages mean.  Hopefully someone can make sense of some of this:

    GPResult:

    Group Policy Local Users and Groups Failed 2/26/2010 3:42:30 PM 
    Group Policy Local Users and Groups failed due to the error listed below.

    The data is invalid. 

    Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 2/26/2010 3:42:30 PM and 2/26/2010 3:42:30 PM. 
     
    EventLog:

    Log Name:      Application
    Source:        Group Policy Local Users and Groups
    Date:          2/26/2010 3:42:30 PM
    Event ID:      8194
    Task Category: (2)
    Level:         Error
    Keywords:      Classic
    User:          SYSTEM
    Computer:      testpc.mynet.local
    Description:
    The client-side extension could not remove computer policy settings for 'Preferences - Local PC Admin Password {9875C3CF-349A-4D12-AFBB-FF66A0AA0936}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Group Policy Local Users and Groups" />
        <EventID Qualifiers="34305">8194</EventID>
        <Level>2</Level>
        <Task>2</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2010-02-26T20:42:30.000000000Z" />
        <EventRecordID>112846</EventRecordID>
        <Channel>Application</Channel>
        <Computer>testpc.mynet.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data>remove</Data>
        <Data>computer</Data>
        <Data>Preferences - Local PC Admin Password {9875C3CF-349A-4D12-AFBB-FF66A0AA0936}</Data>
        <Data>0x8007000d The data is invalid.</Data>
      </EventData>
    </Event>

    GP Event Log:

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          2/26/2010 3:42:30 PM
    Event ID:      7016
    Task Category: None
    Level:         Error
    Keywords:      
    User:          SYSTEM
    Computer:      testpc.mynet.local
    Description:
    Completed Group Policy Local Users and Groups Extension Processing in 249 milliseconds.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-GroupPolicy" Guid="{AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}" />
        <EventID>7016</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>2</Opcode>
        <Keywords>0x4000000000000000</Keywords>
        <TimeCreated SystemTime="2010-02-26T20:42:30.795473100Z" />
        <EventRecordID>619948</EventRecordID>
        <Correlation ActivityID="{0439105C-9CEB-4181-9460-B8FC4E54E7D7}" />
        <Execution ProcessID="1040" ThreadID="2284" />
        <Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
        <Computer>testpc.mynet.local</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="CSEElaspedTimeInMilliSeconds">249</Data>
        <Data Name="ErrorCode">2147942413</Data>
        <Data Name="CSEExtensionName">Group Policy Local Users and Groups</Data>
        <Data Name="CSEExtensionId">{17D89FEC-5C44-4972-B12D-241CAEF74509}</Data>
      </EventData>
    </Event>

    GPsvc.log excerpt:

    GPSVC(3f0.4d4) 14:36:19:812 ProcessGPOs: Processing extension Group Policy Local Users and Groups
    GPSVC(3f0.4d4) 14:36:19:813 ReadStatus: Read Extension's Previous status successfully.
    GPSVC(3f0.4d4) 14:36:19:813 CompareGPOLists:  One list is empty
    GPSVC(3f0.4d4) 14:36:19:830 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0
    GPSVC(3f0.4d4) 14:36:19:831 LockPolicySection called for user <Machine>
    GPSVC(3f0.4d4) 14:36:19:831 Sync Lock Called
    GPSVC(3f0.4d4) 14:36:19:832 Writer Lock got immediately.
    GPSVC(3f0.4d4) 14:36:19:832 Lock taken successfully
    GPSVC(3f0.4d4) 14:36:19:833 ProcessGPOList: Entering for extension Group Policy Local Users and Groups
    GPSVC(3f0.4d4) 14:36:19:833 MachinePolicyCallback: Setting status UI to Applying Group Policy Local Users and Groups policy...
    GPSVC(3f0.4d4) 14:36:19:834 GetWbemServices: CoCreateInstance succeeded
    GPSVC(3f0.4d4) 14:36:19:836 ConnectToNameSpace: ConnectServer returned 0x0
    GPSVC(3f0.4d4) 14:36:19:846 LogExtSessionStatus: Successfully logged Extension Session data
    GPSVC(3f0.4d4) 14:36:20:022 ProcessGroupPolicyCompletedExInternal: Entering. Extension = {17D89FEC-5C44-4972-B12D-241CAEF74509}, dwStatus = 0x8007000d
    GPSVC(3f0.4d4) 14:36:20:024 GetWbemServices: CoCreateInstance succeeded
    GPSVC(3f0.4d4) 14:36:20:026 ConnectToNameSpace: ConnectServer returned 0x0
    GPSVC(3f0.4d4) 14:36:20:027 ProcessGroupPolicyCompletedExInternal: Extension {17D89FEC-5C44-4972-B12D-241CAEF74509} was able to log data. Error = 0x0, dwRet = -2147024883. Clearing the dirty bit
    GPSVC(3f0.4d4) 14:36:20:028 ProcessGroupPolicyCompletedExInternal: Finished processing extension <Group Policy Local Users and Groups> at 72758 ticks (ms)
    Friday, February 26, 2010 10:39 PM

Answers

  • Hi,

    1) Yes, the ADMX file will have versioning built in and will not be tied to an operating system version.
    More information at: http://msdn.microsoft.com/en-us/library/bb204768(VS.85).aspx

    2) For a mixture of Windows 7, XP, 2003, 2008 and 2008 R2, it's recommended to use the last version of ADMX files (Windows 2008 R2 and Windows 7) to retrieve the new policy settings.

    Regards,
    Wilson Jia
    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Wilson Jia Friday, March 5, 2010 7:19 AM
    Friday, March 5, 2010 6:18 AM

All replies

  • Hi RandomAdmin,

     

    Thank you for posting here.

     

    Based on your description, I understand your GPO does not apply to Windows 7 client.

     

    According to the event log, most likely, this issue occurs because the Group Policy client-side extension tries to load the history file that is stored at the following location:

     

    ..\users\All Users\Microsoft\Group Policy\History\<GUID>\Preferences


    However, when the history file is corrupted or unreadable, the group policy preference settings are not applied successfully.

     

    To work around this issue, follow these steps:

    1. Delete the corrupted XML file or local XML file which size is 0 kb in the following location:

    ..\users\All Users\Microsoft\Group Policy\History\< GUID >\Preferences

    2. Run the following command at the command prompt to refresh the group policy again

    gpupdate /force

     

    For more information, you can refer to:

     

    977564  Error message on a domain controller that is running Windows Server 2008: "The client-side extension could not remove user policy settings for 'Domain Name {GUID}' because it failed with error code '0x8007000d The data is invalid.'"

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;977564

     

    Sincerely,

    Wilson Jia

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by Wilson Jia Monday, March 1, 2010 3:41 AM
    Monday, March 1, 2010 3:41 AM
  • I looked Article 977564, and I have a strange follow-up question.  When I open Group Policy Editor on my Domain Controller (2008 R2), and my windows 7 PC, I do not see the option to enable logging and tracing.  Am I using a "bad" version of the Group Policy definitions? 
    Monday, March 1, 2010 8:10 PM
  • Hi,

    You can enable the relevant logging and tracing under the policy [Computer Configuration | Administrative Templateds | System | Group Policy | Logging and tracing].

    Regards,
    Wilson Jia
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, March 2, 2010 3:28 AM
  • I understood that it should be there.  What I am saying is that "Logging and Tracing" option is not there.      
    Tuesday, March 2, 2010 2:31 PM
  • I took a look further into this issue, and I noticed that my root domain is pulling from a Central GPO store.  I have a child domain where the DCs are pulling their GPO's from a local copy.  In the child domain, the "Logging and Tracing" option is there.  Consequently, I am left to assume that I have a problem with the GPOs in our Central Store.  
    Don't get me wrong, the initial issue I started with was due to a corrupt local copy on the PC in question.
    Tuesday, March 2, 2010 8:10 PM
  • Hi RandomAdmin,

    Thank you for your reply.

    Based on your description, I understand that this issue might be caused by ADMX files missing on PDC's central store.

    Please check the following post's solution to see if it fixes the issue.

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/c797b9b1-e1cc-4e26-9ea0-6b7b5906ace2 

    Regards,
    Wilson Jia
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, March 3, 2010 3:18 AM
  • Thanks again Wilson.  I ended up copying the ADMX files from the Child Domain PDC to the Parent Domain PDC, and then the Logging and Tracing reappeared.  The odd part is that our Central store was created with Windows 7 ADMX files, although I think the Windows 7 PC in question may have been upgraded from Vista.  This leads me to the following questions:

    1) Is there a way to tell the "version" of an ADMX file?  

    2) If my network is a mixture of Windows 7, XP, 2003, 2008 and 2008 R2, what ADMX "versions" should I be using?
    Wednesday, March 3, 2010 3:16 PM
  • Hi,

    1) Yes, the ADMX file will have versioning built in and will not be tied to an operating system version.
    More information at: http://msdn.microsoft.com/en-us/library/bb204768(VS.85).aspx

    2) For a mixture of Windows 7, XP, 2003, 2008 and 2008 R2, it's recommended to use the last version of ADMX files (Windows 2008 R2 and Windows 7) to retrieve the new policy settings.

    Regards,
    Wilson Jia
    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Wilson Jia Friday, March 5, 2010 7:19 AM
    Friday, March 5, 2010 6:18 AM
  • In my case Wilson Jia was absolutely right
    Wednesday, December 15, 2010 9:42 AM
  • I have been searching for over a month for this solution and finally one site showed the problem.  It all related to the GPO Cache. See  linkhttp://www.orcsweb.com/blog/rick/resolving-group-policy-error-0x8007000d/

    JohnCCTSIT

    Friday, November 15, 2013 2:24 PM