ADEssentials: PowerShell helpers for keeping Active Directory healthy

What the module is for

ADEssentials is a PowerShell module containing a set of commands that are useful for day to day activities when working with Active Directory. That description is deliberately narrow, and it is the right way to think about the project.

This is not a directory management SDK. It is a collection of targeted health checks and repairs for the things that go wrong in a real Active Directory estate and that nobody has time to write from scratch: duplicate DNS entries, duplicate DNS records pointing at the same address, duplicate service principal names, insecure LDAP bindings, nested group membership that nobody can draw on paper, trusts, DFS health and AD FS.

The list of linked write-ups in the project documentation is effectively a table of contents for the module's feature set, and it reads as a list of recurring support tickets. Finding duplicate DNS entries using PowerShell, finding duplicate DNS records by IP address, finding duplicate SPN, monitoring LDAPS connectivity and certificate, visually displaying nested group membership, visually displaying trusts, an Active Directory DFS health check, and four commands to track down insecure LDAP bindings. Each of those is a script someone wrote to answer a question during an incident, and the module's value is that the question is already answered and packaged.

The primary language is PowerShell, the default branch is master, and the recent releases are v1.0.5 on 2026-09-20, v1.0.4 on 2026-05-06 and v1.0.3 on 2026-05-06. The last push was on 2026-10-09 and the repository is not archived, and its recent releases are tagged as repository releases rather than being limited to the PowerShell Gallery.

It is a dependency of two other tools, not a standalone project

The most informative line in the documentation is that ADEssentials is also an essential part of GPOZaurr and Testimo.

That tells you two things. The first is that the module is load-bearing for somebody else's product: if a function in ADEssentials changes behaviour, GPOZaurr and Testimo change with it. The second is that the module is being exercised by two consumers in production, which is a more meaningful test than the module's own test suite.

The repository layout reflects a mature PowerShell module rather than a script collection. There is ADEssentials.psd1 as the manifest and ADEssentials.psm1 as the module, with a Public/ directory for the exported commands, a Private/ directory for the internals, and separate Tests/ and ADEssentials.Tests.ps1 for the test suite. There is a Build/ directory, a Docs/ directory, a Website/ directory, an Assets/ directory, and an Examples/ directory.

The Examples/ directory is the more revealing part, because it is not a set of small demonstrations. It holds ACL examples, a set of DHCP analysis scripts including Example-DHCPAnalysis.ps1, Example-DHCPFailoverMismatches.ps1, Example-DHCPFailoverPerSubnetDemo.ps1, and a family of Example-DHCPSummary scripts that differ in what they include and exclude, with Full, ExcludeComponents, IncludeScopes-Full, IncludeServers-FailoverOnly, and a Minimal family with AllEnabled and FailoverOnly variants. Then there are Example.01-FindUnknownPermissionsNetlogon.ps1 and its report and remove counterparts, Example.03-EnableInstantReplication.ps1, Example.05-GetSiteLinks.ps1, Example.06-CheckLastBackup.ps1, Example.06-TestLDAPPorts.ps1, Example.07-VerifyADFSHealth.ps1, Example.09-GroupMembershipNested.ps1, Example.10-ListEmailAddresses.ps1 and Example.11-RepairEmailAddress.ps1.

That is a module with a substantial command surface and a real body of operational examples, not a handful of helpers.

Installing and updating, and the maintainer's warning about auto-update

Installation is a single PowerShell Gallery command.

Install-Module -Name ADEssentials -AllowClobber -Force

The documentation adds that Force and AllowClobber aren't necessary, but they do skip errors in case some appear. That is a practical note rather than a recommendation, since a module that collides with an existing command is exactly the case where you want to see the error.

Updating is the mirror image.

Update-Module -Name ADEssentials

And then the paragraph that is worth reading twice, because it is the maintainer's own operational advice rather than a feature description. The essential thing is that if something works for you on production, keep using it until you test the new version on a test computer. The reasoning given is that changes may not be big, but big enough that auto-update may break your code, and the example given is a small rename to a parameter, at which point your code stops working.

There is a practical detail attached: you may need to close and reopen the PowerShell session if you have already used the module before updating it, because the loaded commands are what the session is holding.

The advice is more than caution about a volatile project. It reflects what this module actually is, a set of administrative commands where a renamed parameter or a changed default quietly breaks a scheduled script that runs at three in the morning and reports nothing. Pinning a version that works and testing upgrades on a machine that is not the production one is the difference between a controlled change and a silent outage.

The module is also installed from the PowerShell Gallery, so the same version pinning works through the gallery's version constraints rather than by tracking a repository checkout.

What the health checks actually look for

The linked articles describe what each check inspects, and the set is coherent: they are all conditions that are legal in Active Directory, invisible in day to day operation, and expensive when they accumulate.

Duplicate DNS entries matter because a name resolving to two addresses sends traffic somewhere you did not intend, and the same problem in reverse, two names for one address, breaks anything that hard-codes the name. Duplicate SPN is the Kerberos equivalent, and it produces duplicate tickets and authentication failures that are notoriously hard to trace. The LDAPS monitoring article covers the certificate on the domain controller, which is the failure that takes authentication down for every service at once. The insecure LDAP bindings article predates the March 2020 deadline that pushed the industry to stop signing LDAP traffic, and those four commands are the historical check for whether that migration actually completed.

The visualisation articles are a different category. Nested group membership and Active Directory trusts are both relationships that humans cannot hold in their heads past a certain size, and both are security boundaries, because a group's effective members are the union of every group nested inside it. The DFS health check is about replication of the distributed namespace.

The DHCP examples in the repository follow the same pattern for a different service, with failover mismatches analysed per subnet, summaries that can be scoped to full, to certain scopes, or to failover-only servers, and an option to exclude components. The Examples.01 series on unknown permissions in Netlogon is a least-privilege audit with a report, a remove variant and a find variant, which is the shape of a remediation you can run in stages.

Where this module does not reach

There are three limits, and the first is the one that decides whether you need it at all.

The first is that the scope is diagnosis and repair of specific conditions, not general directory administration. Creating users, moving objects, managing group policy and administering DNS zones are not what this module is for, and expecting a full SDK here will disappoint. Its value is concentrated in the checks listed in the documentation, and it is real value because each of those is a script that would otherwise be written during an incident.

The second is the licensing question, and it is unresolved in what the repository states. The licence field on the repository reads unknown, and the metadata does not name a licence the way the sibling projects in this ecosystem do. If you are running ADEssentials inside an organisation with a policy on third party PowerShell modules, the licence file in the tree is the thing to read, and it is a small but real gate before you install it on a jump box.

The third is the coupling to Active Directory itself. The module talks to a directory, so it needs domain connectivity, appropriate credentials, and a PowerShell environment with the ActiveDirectory module available. That makes it unsuitable for a CI pipeline that runs against a mock or for an offline review, and it means the checks are only as good as the permissions of the account you run them with. A check that cannot enumerate the objects it is meant to inspect will report a clean estate rather than an error, which is a failure mode worth knowing about before you rely on a scheduled run.

On the alternative, the honest comparison is with running the same checks by hand in the PowerShell ActiveDirectory module, which is what most administrators do once and then rewrite. The module saves that rewrite and keeps the checks consistent across environments, and it is the shared layer that GPOZaurr and Testimo already depend on.

Editorial conclusion

Adopt ADEssentials if you administer Active Directory from PowerShell and want ready-made health checks for DNS hygiene, LDAP security, group nesting and AD FS, since those are the jobs it was written for. Do not adopt it if you need a broad management SDK, since the module is a set of targeted diagnostic and repair commands. Before you install it, note the licence is not stated in the repository metadata, and take the maintainer's own advice to pin a version that works in production rather than letting auto-update move underneath you.

Frequently asked questions

Official sources

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