In a previous blog post, I explained that Group Policy (GP) desperately needs reporting and that such a feature should work similar to the postal service’s delivery confirmation.

In this post, I will discuss what I believe the reporting should look like.  And I won’t have to paint a picture with words for you to visualize this because it already exists today… in System Center Configuration Manager (SCCM).

SCCM is Microsoft’s systems management software that enables administrators to manage workstations through the IT lifecycle. It has many features.

The one feature that is of interest here is the reporting available for monitoring package deployments because GP needs something almost identical.

But first I’d like to give my definition of the ambiguous word “package.”

I consider a package to be an envelope (see how I’m skillfully keeping the postal service analogy going) for anything that is to be deployed to a system, such as software, scripts, and etc. So, a package is not applied to the system. Rather, it is delivering what is going to be applied. Therefore, conceptually,  envelops, GPOs, and packages are all similar they deliver stuff.


Seeing how they all relate is important for understanding why we could take something from SCCM and incorporate it in GP. After all, what’s good for the goose is good for the gander – right?

SCCM already has delivery confirmation (another indication that GP has some catching up to do). When a package is deployed, the client-side agent performs the necessary work and then sends a status back to the server. At any time the administrator can monitor the status of the deployment and know, at a minimum, the following:

  • The total number of systems targeted (item 1 below).
  • The systems that did or didn’t receive it (items 2, 3, and 4 below).
  • Whether it applied successfully (items 2 and 3 below).




But that’s not all. In addition to summary information (i.e., completion statistics), you also have access to detailed information such as the computer names, dates and times of execution, and etc. SCCM already does exactly what GP should be doing.

To recap, if GP were to have reporting, it should be almost identical to what SCCM currently has for packages. It should have:

  • Aggregated summary information presented in an eye-friendly chart.
  • Itemized detailed information in a table.

And GP administrators should be able to know:

  • The number of targeted systems (Targeted). And of those targeted…
    • Those that didn’t receive the GPO (Unknown).
    • Those that did receive the GPO and it was successful (Success)
    • Those that did receive the GPO but it failed (Failed).

Now we know not only what GP is missing, but also how this missing component should look and feel; and what information it should provide to administrators. In another blog post, we’ll look at a Microsoft tool that almost addressed GP’s shortcomings.