GPOZaurr: one PowerShell command that audits and repairs Active Directory Group Policy

One command, around twenty reports

GPOZaurr is a PowerShell module whose stated purpose is to gather information about Group Policies and also to allow fixing issues found in them. The README expands that into a claim of 360 degrees of information about Group Policies and their settings, and then delivers on it in a specific way: a single command, Invoke-GPOZaurr, produces the reports.

The report list is the module's core output and it is worth reading as a checklist of what can go wrong in an Active Directory domain. GPOBroken covers policies that are broken. GPOBrokenLink covers links that point nowhere. GPOOwners lists owners. GPOConsistency and GPODuplicates cover policies that contradict or overlap each other. GPOOrganizationalUnit maps policies to the organisational units they apply to, and GPOList and GPOLinks cover enumeration and link structure.

Then a large block of permission reports, which is the part that reflects how much of a domain administrator's week is spent on delegation: GPOPermissions, GPOPermissionsAdministrative, GPOPermissionsRead, GPOPermissionsRoot and GPOPermissionsUnknown. GPOPermissionsUnknown in particular is the one to notice, since it is by definition the set of permissions that nobody has claimed responsibility for, which is where privilege creep lives.

The remaining reports cover the operational layer. GPOPassword reports on password policies set in Group Policy, GPOFiles on the files behind the policies, GPOBlockedInheritance on OU inheritance that has been switched off, GPOAnalysis and GPOUpdates on what is configured and what has changed. NetLogonOwners and NetLogonPermissions look at the classic netlogon share, and SysVolLegacyFiles finds leftover files in the SYSVOL share that no longer correspond to anything.

The claim of over 50 other commands on top of the reports is the second part of the pitch, described as making it more powerful for day to day tasks to manage Group Policies. The README also points to a blog post explaining the usage of Invoke-GPOZaurr.

Installing RSAT, and the warning about workstations

There is a prerequisite that shapes where this module can run, and the README is direct about it. GPOZaurr requires RSAT installed to provide results, and if you do not have it you can install it as below.

# Windows 10 Latest
Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
Add-WindowsCapability -Online -Name 'Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0'

The warning that follows matters more than the commands. The RSAT packages also install GUI tools, so it shouldn't be installed on user workstations. That is a sensible constraint, since the module is a domain administration tool, and it also means the machine running it needs elevated rights to add the Windows capability in the first place.

Two capabilities are needed rather than one. The Active Directory DS-LDS tools cover directory services, and the Group Policy management tools cover the policy side. A machine with only the second will not be able to enumerate domains and organisational units properly.

The module itself then installs from the PowerShell Gallery:

Install-Module -Name GPOZaurr -AllowClobber -Force

The README explains the two flags rather than leaving them unexplained. Force and AllowClobber aren't necessary, but they do skip errors in case some appear. That is worth understanding, because -Force will overwrite an existing version and -AllowClobber lets the module's commands take precedence over existing commands with the same name, and both of those are the sort of thing that causes confusion in a shared administration environment where other modules already define similar verbs.

The repository is the EvotecIT/GPOZaurr project and the module is published on the PowerShell Gallery under the name GPOZaurr, with the badges at the top of the README pointing at the gallery page, the GitHub license badge, the download count and the primary language. The author is Przemyslaw Klys, with links to a blog at evotec.xyz, a Twitter account and a LinkedIn profile. The topic tags are activedirectory, gpo, group-policy, powershell and hacktoberfest.

Updating, and the author's advice not to auto-update production

The updating section is three lines of command and one paragraph of warning, and the paragraph is the valuable part.

Update-Module -Name GPOZaurr

The README notes that you may need to close and reopen the PowerShell session if you have already used the module before updating it, which is the usual PowerShell module loading behaviour rather than anything specific to this project.

Then the advice, which is stated as the essential thing. If something works for you on production, keep using it until you test the new version on a test computer. The author's reason is that changes may not be big but are big enough that auto-update may break your code, and the example given is a small rename to a parameter, after which your code stops working.

That is a more specific and more credible warning than a generic advice to pin versions, because it names the actual failure mode. A Group Policy administration module that renames a parameter is not a hypothetical: the reports are consumed by other automation, and the module is also used to make changes, so a parameter rename turns a working remediation script into a script that throws on a new parameter, potentially halfway through a batch of policy repairs.

The release history backs up the pattern. The three recent releases are v1.1.11 on 2026-09-20, v1.1.10 on 2026-05-22 and v1.1.9 on 2024-12-02. The gap between v1.1.9 in December 2024 and v1.1.10 in May 2026 is a long one for a patch line, and the module is still on a 1.1 version number with a fairly deep history, which is consistent with a tool that has stabilised its interface.

The repository is not archived and the last push was on 2026-10-09, so work is still landing. There is a CHANGELOG.MD in the repository, which is where a responsible administrator would look before upgrading rather than relying on the module's own update behaviour.

One detail in the repository metadata deserves a flag rather than a conclusion. The licence field is recorded as unknown, and the README carries a GitHub license badge, so a licence file exists somewhere in the repository that the metadata did not resolve. For a module that runs with domain admin rights and is imported into shared administration workstations, reading that file before you adopt it is a reasonable precaution, since the badge alone does not tell you which licence applies.

The Examples directory is the real documentation of what the module can change

The repository listing shows a module laid out the way mature PowerShell projects are. There is a Public/ directory and a Private/ directory, which is the conventional split between exported cmdlets and internal helper functions. There is a Tests/ directory and a separate GPOZaurr.Tests.ps1, plus an Examples/ directory, a Docs/ directory, a Website/ directory, a Build/ directory, and the module manifest and loader at the root as GPOZaurr.psd1 and GPOZaurr.psm1.

The Examples directory is where the destructive side of the tool becomes clear, and it is long. The file names run in numbered order and read like a menu.

Backup and restore are first, with Example-01-BackupGPOs.ps1, Example-03-RestoreGPO.ps1 and Example-02-RemoveEmptyAndUnlinkedGPOs.ps1, which is a cleanup operation that deletes policies. From there the list moves through WMI filter listing and removal and creation across Examples 05, 06 and 07, then a block of permission listings at Example-08 covering general, administrative, per GPO and unknown permissions, followed by three removal scripts for unknown permissions and named permission removal.

Then listing policies in two variants, and a five part series on replacing GPO owners, which is where the naming gets specific: automated, manual, per GPO, with exclusions, and a plain replace. The fact that owner replacement is split into automated, manual, per GPO and with-exclusions variants says something about how fiddly ownership delegation is in a real domain.

Two things follow from the directory listing. The first is that this module is not read only, despite the framing around reports, and there are scripts here that delete GPOs, remove permissions and change owners. The second is that the example scripts are a form of documentation that is more concrete than a cmdlet list, and the README's own guidance about testing on a test computer before applying changes to production is consistent with a module that can remove permissions from a domain.

The Docs/ and Website/ directories suggest the documentation is generated rather than maintained by hand, and the CHANGELOG.MD gives you the version history to read before an upgrade.

What the tool is for, and where it stops

It is worth being clear about the category this module belongs to, because the name suggests a reporting tool and the repository shows a remediation tool.

GPOZaurr is a domain administration tool. It talks to Active Directory through the Group Policy management interfaces that RSAT installs, and it exists because auditing Group Policy by hand in a large domain is slow and incomplete. The report list is the audit, and the fix commands are the remediation. The README describes it as a module that aims to gather information about Group Policies but also allows fixing issues that you may find in them, and the order of those clauses is the right order to read them in.

The scope boundary is Windows Active Directory. There is no cross platform story, no Azure AD equivalent mentioned, and the RSAT dependency rules out anything that is not a Windows machine with the management tools. For an environment that is all Azure AD, or a Linux shop with a Samba domain, the module simply does not apply.

The other boundary is the one the README is most careful about, which is that this tool can make changes. A module that both reports on permissions and removes them is a module where a mistyped parameter can lock administrators out of an OU. The mitigation the author gives is procedural rather than technical: test on a test computer, keep the working version in production until you have tested the new one.

There is also a maintenance consideration specific to a tool like this. Group Policy management interfaces change between Windows versions, and the module is versioned with the Windows feature it depends on. The README's Windows 10 Latest comment on the RSAT commands is a small signal that the module targets a current Windows release, and a module that automates against RSAT will need revisiting when a new Windows feature update changes the underlying interfaces.

The final thing to weigh is the licensing question that the metadata did not answer. The repository is under the EvotecIT organisation and the module is on the PowerShell Gallery, and the licence badge in the README points to a file in the repository. Read it, then read the CHANGELOG.MD, then run Invoke-GPOZaurr against a test domain before you let it anywhere near production.

Editorial conclusion

GPOZaurr fits a Windows administrator or helpdesk team that has inherited a domain with messy Group Policy and wants a repeatable read of what is broken before touching anything, since the reports are the deliverable and the fixing commands are separate. It is the wrong tool for a non Active Directory environment, or for a workstation, because the RSAT features it needs also install GUI tools and the README says it should not be installed on user workstations. Before running Invoke-GPOZaurr against a production domain, test the new module version on a test computer as the README advises, because a renamed parameter is enough to break automation that depends on it.

Frequently asked questions

Official sources

1. EvotecIT/GPOZaurr on GitHub
2. Issues
3. README
4. Releases