| Author | Messages | |
jeromelcruz
Posts:120
 | | 01/13/2010 8:51 PM |
| Does anyone have a list of errors (and possible resolutions for them) for:
A) The GPPE sub-systems as released by Microsoft or
B) The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| dmarelia
Posts:394
| | 01/15/2010 11:41 PM |
| Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
1. The GPPE sub-systems as released by Microsoft or
2. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
[cid:image001.jpg@01CA95F8.E17E76B0]
[cid:image002.jpg@01CA95F8.E17E76B0]
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| jeromelcruz
Posts:120
| | 01/15/2010 11:56 PM |
| Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
1. The GPPE sub-systems as released by Microsoft or
2. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| dmarelia
Posts:394
| | 01/16/2010 12:06 AM |
| Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
1. The GPPE sub-systems as released by Microsoft or
2. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| chrisellis
Posts:4
| | 01/18/2010 3:20 AM |
| I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
1. The GPPE sub-systems as released by Microsoft or
2. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
| | | |
| chrisellis
Posts:4
| | 01/20/2010 8:45 PM |
| As a follow-up to this. I ended up opening a ticket with Microsoft. We deleted the GP history hive in the registry then did a gpupdate /force and everything started working. The theory is at some point the machine got confused about the policy and didn't know what to apply so it applied nothing.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History
We backed it up the before we deleted and you probably should too.
Also, in addition to the 8194 error, it was always coupled with a 1085 error.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 8:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
1. The GPPE sub-systems as released by Microsoft or
2. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
| | | |
| jeromelcruz
Posts:120
| | 01/21/2010 12:56 AM |
| Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
1. The GPPE sub-systems as released by Microsoft or
2. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
| | | |
| dougdelaney
Posts:43
| | 01/21/2010 3:48 AM |
| Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
Technology Consultant III
Americas Regional Delivery Engineering
HP Enterprise Services
Telephone +1 248.365.9187
Mobile +1 248.210.4973
Email xxxxxxxxxxxxxxxx<mailto xxxxxxxxxxxxxxxx>
985 W. Entrance Dr., 2A / Auburn Hills, MI 48326
[cid:image002.jpg@01CA9A21.AFA40240]
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A. The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
| | | |
| jeromelcruz
Posts:120
| | 01/22/2010 12:44 AM |
| No, the 'Apply once and do not re-apply' setting is not engaged for the "Update" action preference.
I just looked at the verbose log the SA forwarded and was able to glean two additional tidbits of information from it that I'm having the SA follow up with.
...
Started removing policy.
GPH data file : C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}\Machine\Preferences\Registry\Registry.xml
Read GPH data file.
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
...
The error apparently occurs when trying to remove/read the 'local' copy of the XML file.
Actions for the SA
* Log onto the server, make a copy of that file, and forward it back to me (is the data 'really' invalid?).
* Check the permissions on that folder and the file and see if System has Full Control access to them (note whether the permissions are inherited or explicitly defined). If System does not have access, check step-by-step back up the folder path to see where this might have been changed.
If those do not point to the issue, I am going to have the SA make sure that System has access permissions at C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History and then delete the folder path (from the GUID folder portion under C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501 on down) and then manually refresh policies with the GPUpdate /force command.
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Wednesday, January 20, 2010 7:41 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A.
The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| jeromelcruz
Posts:120
| | 01/22/2010 1:23 AM |
| No, the 'Apply once and do not re-apply' setting is not engaged for the "Update" action preference.
I just looked at the verbose log the SA forwarded and was able to glean two additional tidbits of information from it that I'm having the SA follow up with.
...
Started removing policy.
GPH data file : C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}\Machine\Preferences\Registry\Registry.xml
Read GPH data file.
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
...
The error apparently occurs when trying to read or remove the 'local' XML file.
Actions for the SA
* Log onto the server, make a copy of that file, and forward it back to me (is the data 'really' invalid?).
* Check the permissions on that folder and the file and see if System has Full Control access to them (note whether the permissions are inherited or explicitly defined). If System does not have access, check step-by-step back up the folder path to see where this might have been changed.
If those do not point to the issue, I am going to have the SA make sure that System has access permissions at C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History and then delete the folder path (from the GUID folder portion under C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501 on down) and then manually refresh policies with the GPUpdate /force command.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Wednesday, January 20, 2010 7:41 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
Technology Consultant III
Americas Regional Delivery Engineering
HP Enterprise Services
Telephone +1 248.365.9187
Mobile +1 248.210.4973
Email xxxxxxxxxxxxxxxx<mailtoxxxxxxxxxxxxxxxx>
985 W. Entrance Dr., 2A / Auburn Hills, MI 48326
[cid:image001.jpg@01CA9AA2.5EEB9F80]
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A. The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
| | | |
| dmarelia
Posts:394
| | 01/22/2010 1:23 AM |
| For what its worth, if it were a permissions issue, I would expect you to see a message other than "the data is invalid". But it will be interesting to see.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Thursday, January 21, 2010 3:53 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
No, the 'Apply once and do not re-apply' setting is not engaged for the "Update" action preference.
I just looked at the verbose log the SA forwarded and was able to glean two additional tidbits of information from it that I'm having the SA follow up with.
...
Started removing policy.
GPH data file : C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}\Machine\Preferences\Registry\Registry.xml
Read GPH data file.
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
...
The error apparently occurs when trying to remove/read the 'local' copy of the XML file.
Actions for the SA
* Log onto the server, make a copy of that file, and forward it back to me (is the data 'really' invalid?).
* Check the permissions on that folder and the file and see if System has Full Control access to them (note whether the permissions are inherited or explicitly defined). If System does not have access, check step-by-step back up the folder path to see where this might have been changed.
If those do not point to the issue, I am going to have the SA make sure that System has access permissions at C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History and then delete the folder path (from the GUID folder portion under C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501 on down) and then manually refresh policies with the GPUpdate /force command.
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Wednesday, January 20, 2010 7:41 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A. The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| jeromelcruz
Posts:120
| | 01/22/2010 2:36 AM |
| We think we've got it resolved. The local copy of the preference's XML file was apparently corrupted. I had compared the copy sent to me by the SA with the master copy on the server in SYSVOL. The version the SA returned to me was essentially garbage from an XML standpoint. I believe that the local copy was actually stored in a totally different text format because the copy sent to me was in ANSI encoding, whereas the one I accessed directly in the GPO in SYSVOL was UTF-8 encoded.
Now the file 'was' e-mailed to me, so I suppose it's possible the format of the attachment changed during that process. That doesn't seem likely. Also, even though System had Full Control access permissions to the XML file on the local server, the mechanisms used by Group Policy were not able to delete and replace the file in the state that it was in on the server. In fact, that may possibly imply that the mechanisms used to update do not delete/copy, but perhaps perform an open/write instead. If the local copy of the file was in ANSI format, and the writing mechanism opened it for writing UTF-8 encoded format, then that could have been the cause of the error.
The SA now reports the following:
I think that worked, no error in the event log this time, instead:
Event Type: Information
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 4096
Date: 1/21/2010
Time: 4:35:33 PM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The computer 'MaxSize' preference item in the 'DSP (GRP NTI 206-797-2885) {C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}' Group Policy object applied successfully.
And
Event Type: Information
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 4096
Date: 1/21/2010
Time: 4:35:33 PM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The computer 'Retention' preference item in the 'DSP (GRP NTI 206-797-2885) {C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}' Group Policy object applied successfully.
We'll be checking the event logs again in the morning to make sure this sticks. If so, then the remaining questions are 'what corrupted the file in the first place' and 'will that repeat'?
Bottom line, for this kind of 8194 error:
Event Type: Error
Event Source: Group Policy Registry)
Event Category: (2)
Event ID: 8194 (This 8194 error is generic to many Client Extensions)
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for '{GPO_NAME}'
because it failed with error code '0x8007000d The data is invalid.' See trace file
for more details.
This is usually (perhaps always?) accompanied by error 1085:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 1/20/2010
Time: 2:23:09 PM
User: NT AUTHORITY\SYSTEM
Computer: VTR-PSD-12
Description:
The Group Policy client-side extension Group Policy Registry failed to execute.
Please look for any errors reported earlier by that extension.
REPORTED TO WORK RESOLUTIONS
* Reinstall the Preference Client Extensions and refresh GPOs
* Backup the registry hive at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History, then delete the GPO History hive, and refresh GPOs.
* [New] Find the local copy of the Preference's XML file, delete it, and then refresh GPOs.
The local copy of the Preference XML file is stored here (for Windows Server 2003):
C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{GPO_GUID}\Machine (or User)\Preferences\Client_Extension_name\Registry.xml
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, January 21, 2010 5:22 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
For what its worth, if it were a permissions issue, I would expect you to see a message other than "the data is invalid". But it will be interesting to see.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Thursday, January 21, 2010 3:53 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
No, the 'Apply once and do not re-apply' setting is not engaged for the "Update" action preference.
I just looked at the verbose log the SA forwarded and was able to glean two additional tidbits of information from it that I'm having the SA follow up with.
...
Started removing policy.
GPH data file : C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}\Machine\Preferences\Registry\Registry.xml
Read GPH data file.
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
...
The error apparently occurs when trying to remove/read the 'local' copy of the XML file.
Actions for the SA
* Log onto the server, make a copy of that file, and forward it back to me (is the data 'really' invalid?).
* Check the permissions on that folder and the file and see if System has Full Control access to them (note whether the permissions are inherited or explicitly defined). If System does not have access, check step-by-step back up the folder path to see where this might have been changed.
If those do not point to the issue, I am going to have the SA make sure that System has access permissions at C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History and then delete the folder path (from the GUID folder portion under C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501 on down) and then manually refresh policies with the GPUpdate /force command.
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Wednesday, January 20, 2010 7:41 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A. The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| dougdelaney
Posts:43
| | 01/22/2010 2:45 AM |
| My testing has revealed that the xml files are copied to the client from SYSVOL every time the GPO applied (whether is it apply once or not). So, the xml files should have been overwritten from a fresh sysvol copy each GPO processing cycle... so , is there an inconsistency on your sysvol somewhere?
Doug Delaney
Technology Consultant III
Americas Regional Delivery Engineering
HP Enterprise Services
Telephone +1 248.365.9187
Mobile +1 248.210.4973
Email xxxxxxxxxxxxxxxx<mailtoxxxxxxxxxxxxxxxx>
985 W. Entrance Dr., 2A / Auburn Hills, MI 48326
[cid:image003.jpg@01CA9AE2.A458F460]
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Thursday, January 21, 2010 9:36 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
We think we've got it resolved. The local copy of the preference's XML file was apparently corrupted. I had compared the copy sent to me by the SA with the master copy on the server in SYSVOL. The version the SA returned to me was essentially garbage from an XML standpoint. I believe that the local copy was actually stored in a totally different text format because the copy sent to me was in ANSI encoding, whereas the one I accessed directly in the GPO in SYSVOL was UTF-8 encoded.
Now the file 'was' e-mailed to me, so I suppose it's possible the format of the attachment changed during that process. That doesn't seem likely. Also, even though System had Full Control access permissions to the XML file on the local server, the mechanisms used by Group Policy were not able to delete and replace the file in the state that it was in on the server. In fact, that may possibly imply that the mechanisms used to update do not delete/copy, but perhaps perform an open/write instead. If the local copy of the file was in ANSI format, and the writing mechanism opened it for writing UTF-8 encoded format, then that could have been the cause of the error.
The SA now reports the following:
I think that worked, no error in the event log this time, instead:
Event Type: Information
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 4096
Date: 1/21/2010
Time: 4:35:33 PM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The computer 'MaxSize' preference item in the 'DSP (GRP NTI 206-797-2885) {C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}' Group Policy object applied successfully.
And
Event Type: Information
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 4096
Date: 1/21/2010
Time: 4:35:33 PM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The computer 'Retention' preference item in the 'DSP (GRP NTI 206-797-2885) {C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}' Group Policy object applied successfully.
We'll be checking the event logs again in the morning to make sure this sticks. If so, then the remaining questions are 'what corrupted the file in the first place' and 'will that repeat'?
Bottom line, for this kind of 8194 error:
Event Type: Error
Event Source: Group Policy Registry)
Event Category: (2)
Event ID: 8194 (This 8194 error is generic to many Client Extensions)
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for '{GPO_NAME}'
because it failed with error code '0x8007000d The data is invalid.' See trace file
for more details.
This is usually (perhaps always?) accompanied by error 1085:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 1/20/2010
Time: 2:23:09 PM
User: NT AUTHORITY\SYSTEM
Computer: VTR-PSD-12
Description:
The Group Policy client-side extension Group Policy Registry failed to execute.
Please look for any errors reported earlier by that extension.
REPORTED TO WORK RESOLUTIONS
* Reinstall the Preference Client Extensions and refresh GPOs
* Backup the registry hive at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History, then delete the GPO History hive, and refresh GPOs.
* [New] Find the local copy of the Preference's XML file, delete it, and then refresh GPOs.
The local copy of the Preference XML file is stored here (for Windows Server 2003):
C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{GPO_GUID}\Machine (or User)\Preferences\Client_Extension_name\Registry.xml
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, January 21, 2010 5:22 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
For what its worth, if it were a permissions issue, I would expect you to see a message other than "the data is invalid". But it will be interesting to see.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Thursday, January 21, 2010 3:53 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
No, the 'Apply once and do not re-apply' setting is not engaged for the "Update" action preference.
I just looked at the verbose log the SA forwarded and was able to glean two additional tidbits of information from it that I'm having the SA follow up with.
...
Started removing policy.
GPH data file : C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}\Machine\Preferences\Registry\Registry.xml
Read GPH data file.
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
...
The error apparently occurs when trying to remove/read the 'local' copy of the XML file.
Actions for the SA
* Log onto the server, make a copy of that file, and forward it back to me (is the data 'really' invalid?).
* Check the permissions on that folder and the file and see if System has Full Control access to them (note whether the permissions are inherited or explicitly defined). If System does not have access, check step-by-step back up the folder path to see where this might have been changed.
If those do not point to the issue, I am going to have the SA make sure that System has access permissions at C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History and then delete the folder path (from the GUID folder portion under C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501 on down) and then manually refresh policies with the GPUpdate /force command.
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Wednesday, January 20, 2010 7:41 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A. The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
| jeromelcruz
Posts:120
| | 01/22/2010 4:43 PM |
| Not that I can tell. As I noted earlier, this Group Policy is targeting several thousand servers and this is was only device reporting an issue (so far anyway).
What I wouldn't give for some kind of centralized SQL Server storage based GPO health reporting system from Microsoft. This would include system-by-system, GPO specific event logs (such as are available from the GPMC based RSoP reports). It would also include DC side health reporting which would include full SYSVOL content as well as replication status (content as well as permissions) reports. I've broached the idea several times to MS...time will tell.
Jerry Cruz | Group Policies Product Manager | Windows Server and Infrastructure Architecture | Boeing IT
Office 425-865-6755 | Mobile 425-591-6491
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Thursday, January 21, 2010 6:43 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
My testing has revealed that the xml files are copied to the client from SYSVOL every time the GPO applied (whether is it apply once or not). So, the xml files should have been overwritten from a fresh sysvol copy each GPO processing cycle... so , is there an inconsistency on your sysvol somewhere?
Doug Delaney
Technology Consultant III
Americas Regional Delivery Engineering
HP Enterprise Services
Telephone +1 248.365.9187
Mobile +1 248.210.4973
Email xxxxxxxxxxxxxxxx<mailtoxxxxxxxxxxxxxxxx>
985 W. Entrance Dr., 2A / Auburn Hills, MI 48326
[cid:image001.jpg@01CA9B3E.882EDA50]
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Thursday, January 21, 2010 9:36 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
We think we've got it resolved. The local copy of the preference's XML file was apparently corrupted. I had compared the copy sent to me by the SA with the master copy on the server in SYSVOL. The version the SA returned to me was essentially garbage from an XML standpoint. I believe that the local copy was actually stored in a totally different text format because the copy sent to me was in ANSI encoding, whereas the one I accessed directly in the GPO in SYSVOL was UTF-8 encoded.
Now the file 'was' e-mailed to me, so I suppose it's possible the format of the attachment changed during that process. That doesn't seem likely. Also, even though System had Full Control access permissions to the XML file on the local server, the mechanisms used by Group Policy were not able to delete and replace the file in the state that it was in on the server. In fact, that may possibly imply that the mechanisms used to update do not delete/copy, but perhaps perform an open/write instead. If the local copy of the file was in ANSI format, and the writing mechanism opened it for writing UTF-8 encoded format, then that could have been the cause of the error.
The SA now reports the following:
I think that worked, no error in the event log this time, instead:
Event Type: Information
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 4096
Date: 1/21/2010
Time: 4:35:33 PM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The computer 'MaxSize' preference item in the 'DSP (GRP NTI 206-797-2885) {C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}' Group Policy object applied successfully.
And
Event Type: Information
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 4096
Date: 1/21/2010
Time: 4:35:33 PM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The computer 'Retention' preference item in the 'DSP (GRP NTI 206-797-2885) {C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}' Group Policy object applied successfully.
We'll be checking the event logs again in the morning to make sure this sticks. If so, then the remaining questions are 'what corrupted the file in the first place' and 'will that repeat'?
Bottom line, for this kind of 8194 error:
Event Type: Error
Event Source: Group Policy Registry)
Event Category: (2)
Event ID: 8194 (This 8194 error is generic to many Client Extensions)
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for '{GPO_NAME}'
because it failed with error code '0x8007000d The data is invalid.' See trace file
for more details.
This is usually (perhaps always?) accompanied by error 1085:
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 1/20/2010
Time: 2:23:09 PM
User: NT AUTHORITY\SYSTEM
Computer: VTR-PSD-12
Description:
The Group Policy client-side extension Group Policy Registry failed to execute.
Please look for any errors reported earlier by that extension.
REPORTED TO WORK RESOLUTIONS
* Reinstall the Preference Client Extensions and refresh GPOs
* Backup the registry hive at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History, then delete the GPO History hive, and refresh GPOs.
* [New] Find the local copy of the Preference's XML file, delete it, and then refresh GPOs.
The local copy of the Preference XML file is stored here (for Windows Server 2003):
C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{GPO_GUID}\Machine (or User)\Preferences\Client_Extension_name\Registry.xml
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, January 21, 2010 5:22 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
For what its worth, if it were a permissions issue, I would expect you to see a message other than "the data is invalid". But it will be interesting to see.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Thursday, January 21, 2010 3:53 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
No, the 'Apply once and do not re-apply' setting is not engaged for the "Update" action preference.
I just looked at the verbose log the SA forwarded and was able to glean two additional tidbits of information from it that I'm having the SA follow up with.
...
Started removing policy.
GPH data file : C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501}\Machine\Preferences\Registry\Registry.xml
Read GPH data file.
Completed parse of GPH XML. [ hr = 0x8007000d "The data is invalid." ]
...
The error apparently occurs when trying to remove/read the 'local' copy of the XML file.
Actions for the SA
* Log onto the server, make a copy of that file, and forward it back to me (is the data 'really' invalid?).
* Check the permissions on that folder and the file and see if System has Full Control access to them (note whether the permissions are inherited or explicitly defined). If System does not have access, check step-by-step back up the folder path to see where this might have been changed.
If those do not point to the issue, I am going to have the SA make sure that System has access permissions at C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History and then delete the folder path (from the GUID folder portion under C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\History\{C8856B2E-2C32-4E41-8EB6-4C6CAFEDE501 on down) and then manually refresh policies with the GPUpdate /force command.
Jerry
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Delaney, Doug
Sent: Wednesday, January 20, 2010 7:41 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Is this a setting that is configured to apply once and do not re-apply?
[Just noting that I have seen odd behavior with settings that are configured to apply once, not always applying correctly (even the first time) ... And, that creating GPPs without deleting and re-creating the actual registry settings (in the GPO) does not generate a new ID that is unique, so keys left in HKCU (or HKLM\Software\Microsoft\Group Policy\Client\RunOnce as GUID entries that match the id= field in the .xml files for that particular setting). In any case, deleting the above key, and doing a gpupdate /force almost always resolves any apply once issue not applying. Some exceptions I know are power options in XP, applied as the user without the latest roll-up hotfix installed for the CSEs.] I suspect it is a timing issue of when the RunOnce sub keys are written. If written before the entire xml file is processed, some portion of the group of settings is missed. Sorry, I don't yet have empirical data to back that up - just a gut feel.
I am seeing the same behavior on Windows 7 as I have on Windows XP - which is apply once simply doesn't "always" work correctly or completely.
Doug Delaney
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 20, 2010 7:56 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Clearing the History hive and refreshing GPOs had not worked for us. Thanks for the tip on the other error. The SA confirmed that it was there as well (and apologized for not informing me). Still working on this. I'm going to take another close look at the verbose tracing logs.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Ellis, Chris
Sent: Sunday, January 17, 2010 7:15 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
I am having this exact error on only one of several machines that is getting a certain preference policy. I did try reinstalling the CSEs but I didn't un-install and re-install (just a re-install didn't help). I am going to try the un-install and re-install once I get a formal change case open. I am using preferences to set a couple of registry settings, nothing to do with powershell. I tried removing the policy but it won't remove from this machine - I get the same error but instead of listing the policy name it is it blank.
I'll be interested to hear how this goes for you and I will let you know if I find anything.
Chris Ellis
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 5:01 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Interesting Jerry. It does sound like a client-side problem in that case, but seems strange that one server would exhibit it. Reinstalling the CSEs would have been my first guess at trying to fix this. How about oddities in Registry key permissions that could be causing the problem? Let me know how your Powershell uninstall goes.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Friday, January 15, 2010 3:55 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Hi Darren,
Apparently, the error message is unique to one particular server (the GPO is applied to over a thousand servers). I just set up a test server of the same kind to see if it duplicates the error. So far, no duplication or the error. Since the only Group Policy Registry settings in the identified GPO are for PowerShell and the GPO preference controls only two settings, I'm going to try and see what happens if I manually uninstall PowerShell and refresh policies.
Jerry Cruz
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Friday, January 15, 2010 3:40 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] 8194 Group Policy Registry Event Log Error
Just starting to catch up on GPTalk emails! Sorry for the delay Jerry. So, whenever I see a "Data is Invalid" error on GP, I immediately think that something is the settings file is corrupted, or at least not what its supposed to be. Does this happen on this GPO only? Can you isolate the setting to another GPO for testing to see if you get the same error?
I will also ping some folks on the MS side to see if they have any ideas on this one.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Cruz, Jerome L
Sent: Wednesday, January 13, 2010 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: [gptalk] 8194 Group Policy Registry Event Log Error
Does anyone have a list of errors (and possible resolutions for them) for:
A. The GPPE sub-systems as released by Microsoft or
B. The PolicyMaker sub-systems as originally released by the former desktopStandard
I'm hoping that someone out there has a list of these kind of GPPE errors and recommended solutions, either from Microsoft or from the original vendor. I'd really like to know what the (error code '0x8007000d) error actually means and I'd just bet there are other GPO Admins who'd like that list as well.
=========================
I have a System Admin reporting the following error message on one server. The error message is related to the Group Policy Registry GPPE sub-system. After researching this, the error is apparently a 'generic' 8194 error message which can occur in many of the various GPPE sub-systems and has existed as an error since PolicyMaker times.
Event Type: Error
Event Source: Group Policy Registry
Event Category: (2)
Event ID: 8194
Date: 1/12/2010
Time: 5:58:41 AM
User: NT AUTHORITY\SYSTEM
Computer: XXX-XXX-XX
Description:
The client-side extension could not remove computer policy settings for 'GPO_NAME_WAS_HERE {GPO_GUID_WAS_HERE}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
I have not yet had the SA enable verbose tracing yet because, as I researched the error, I found that the 'trace log' essentially repeats the same info (somewhat less concisely). So, I don't expect a trace file to be of assistance in helping to resolve this particular error (though I will show the SA how to enable it and send the data back to me). This preference setting was added to the GPO (several months ago) and the GPO is targeting over a thousand other devices with no other issues being reported (at least not yet!). Browsing the web, I gather that the recommended solutions are: a) reinstalling GPPEs on the problem device, b) deleting the local GPO history and then refreshing GPOs, and c) change the GPO (bump it). None of the forum messages indicated that these work-arounds actually resolved the problem.
Here's what the GPO setting is doing.
If PowerShell is installed, then the MaxSize registry key for it exists under the services hive. If the registry key exists, then the preference Targeting setting configures the registry key's value (and therefore the size of the associated event log) to 40 MB. So, device's with PowerShell installed get the associated event log size set to 40 Mb and those devices that do not have PowerShell installed do not get the registry keys at all.
Okay...Why the fancy filtering? We were planning to just pre-create and populate the devices with the correct MaxSize registry key (40 Mb per Microsoft recommendation). Then, when a System Admin installed PowerShell, the right size would already be in place (or be in place after a background GPO refresh). However, it turns out that if you pre-create this particular registry key, then the Event log system automatically creates a few other registry keys in the same spot, creates a matching event log, and makes that log visible in the Event Viewer. This empty log was unacceptable to many of the Server Admins who were not yet ready to install PowerShell. Using this preference, the log gets properly sized only 'after' PowerShell is installed (i.e. after the registry keys get created).
Jerry Cruz | Group Policies Product Manager | Boeing IT
| | | |
|
|