GPO - Settings - Am error occurred while generating report.

[DennisT]

Hi,
One of my GPOs gives me the following error whenever I try to generate a report or GP results for any object it applies to:

An error occurred while generating report:
An unknown error occurred while the HTML report was being created.

Save report does the same error.

I'm not having a problem with any other GPOs. I even tried copying this GPO to another domain and still get the same results.

Anyone have an idea as to what the problem is? Is there a consistency check tool I can run for this GPO? I have the majority of my users under this GPO and other than the above problem it appears to be applying properly.

Note: I have run admFiles_IE7.msi

[DennisT]

I've run Gpotool and no problems were found.

All that is defined in this GPO is folder redirection.

I've made the same changes to another GPO (higher level) and moved all my users over. That GPO reports without a problem.

[JerryC]

Dennis,

I have encountered this type of thing in one context only. That is when the GPO in SYSVOL or its security was corrupt. We do not have many tools to discover this kind of thing, but the solution has been to recreate the GPO from scratch. As you noted, copyiong to another domain caused the problem to recur (so copying a problem duplicates that problem), so I've had my OU Admins re-create their GPO from scratch and Voila, their problem disappeared.

Try in a test OU first and then apply to production. Why?

Since your GPO uses User-side Folder Redirection, watch out as it may cause a certain amount of user-side activity as the GUIDs change. I do not know what to expect exactly, but I suspect that a little testing should indicate the behavior youll encounter during the switchover.

[DennisT]

The one thing that this has made clear is that I need to revamp my backup/documentation of GPOs. The problem GPO worked fine in all aspects except the ability to generate a report.

[JerryC]

Agreed...

And if you extend my "corrupt GPO" concept, you can see that different GPO entities "read" what they want they need to read from a GPO. For example, a Client Extension DLL might read a piece (or portion) of the GPO that is NOT "corrupt" and therefore apply totally corectly per plan. Whereas another access method (such as the GPMC-based) might read everything and error out.

Example One client lock-down GPO that we encountered had been working just fine in a factory area for several years. They had recently made a minor change to it and the whole thing stopped working entirely. I had them look at the GPO using several tools and in all but one respect, they were the same. One one tool showed some additional settings (Security\Public key configs) that looked out of place to me (especially since none of the other tools reported those settings and it would have been unusual to configure those kinds of policies at that OU level).

When I inquired about the settings, the OU Admins reported that none should be there. I performed a detailed look at all files associated with the GPO and found nothing amiss. What I concluded was that somehow the GPO was corrupt at the disk level. The client extension was able to somehow run past the end of the file and pick up some additional settings that should not have been configured there. The client DLL was seeing the settings and "mis-behaving". Since it was on a DC, I couldn't simply engage a disk-level utility to look at the bits in detail, so the easier solution was to have them re-create the GPO from scratch. They did, the problem went away, we deleted the original. Voila!

Good luck.

[DennisT]

See the thread I started at http://www.gpanswers.com/community/v...hp?p=6189#6189 to reproduce this problem.