# Testimo and the shape of an Active Directory health check that reads as a report

> Testimo is a PowerShell module that runs a battery of Active Directory health checks and renders the results as HTML, with sources and tests separated by their requirements handling. The author calls it an alpha product and says so repeatedly, and the module still does not work on PowerShell 7 because it depends on GroupPolicy and ServerManager.

**EvotecIT/Testimo** — Testimo is a PowerShell module for running health checks for Active Directory against a bunch of different tests

- Repository: https://github.com/EvotecIT/Testimo
- Stars: 652 · Forks: 77
- Language: PowerShell
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/evotecit-testimo

## A module that turns many small checks into one command

Testimo is a PowerShell module to help with basic or more advanced testing of Active Directory, and possibly other types of servers in future. The stated goal is to be a fully automated solution where one can run the command and get results without executing fifty little functions.

That framing explains the design. The alternative to a module like this is a script library where you write the checks yourself, or a collection of one-liners you paste into a console. The value of Testimo is that the checks are already written, already have a consistent shape, and already produce a report you can hand to somebody else.

The output is the second half of the pitch. Running the module produces both console output and an HTML report, and the report is the artifact that matters for an assessment, because it is what you send to a colleague or attach to a ticket.

The honesty about status is striking and worth reading before anything else. The README states that Testimo is an alpha product and as such things do change. It says the configuration hash is not written in stone and can change rapidly as Testimo gets tested, that there is a big mess in file and function names because the author is still testing things out and creating some random names which will be cleaned up later, that there are lots of details missing for tests and some things may not work as you want, and that the author does not know everything.

That is a project telling you exactly what it is. The primary language is PowerShell, the topics are active-directory, powershell, tests and hacktoberfest, and the release tags are v0.0.90 from September 2024, v0.0.92 from September 2026 and v0.0.93 from October 2026, so the version numbers themselves are the alpha status.

## Sources and tests fail differently when requirements are missing

There is a known issues section that describes something by design, and it is the detail that tells you how the module is built.

The rule is that requirements for sources work differently than for tests. For sources, when requirements are not met, Testimo skips it totally from output. For tests, when requirements are not met, Testimo marks it as skipped.

The distinction is a design decision about what a report should say. A source is a connection point, a domain or a forest you are asking about, and if the requirements to reach it are not met then there is nothing to report, so it is dropped from the output entirely. A test is a specific assertion, and if the prerequisites are not there, the right thing to do is record that it was skipped rather than hide the fact that a check did not run.

That is a good distinction and it tells you something about the reporting model. The HTML report is not a list of pass and fail results, it is a record of what was attempted, what was skipped and why. For an Active Directory assessment, that difference is the whole point, because a health check that silently omits a source looks identical to a health check where everything was fine.

The module is organised around the same idea elsewhere. Sources are the things being checked, tests are the individual checks, and both are addressed by name in the parameters you pass to the module.

## It runs on Windows PowerShell, and it says why it cannot run on 7

The compatibility note is the first thing to check before you plan an installation, and it is unambiguous.

At present the module is not supported in PowerShell Core or PowerShell 7. The reason given is that the Testimo module depends on other Microsoft modules that are also not supported in PowerShell 7, and the two named are GroupPolicy and ServerManager. There is an issue tracking this compatibility work, issue 110 in the repository, and the README links it.

That dependency is not accidental. GroupPolicy and ServerManager are Windows-only modules that wrap the Group Policy and Server Manager APIs, and they are part of what an Active Directory assessment touches: whether Group Policy is healthy across the forest, and whether the Server Manager role is in a good state on domain controllers. A cross-platform module cannot use them, so the whole assessment that depends on those checks would have to be restructured rather than ported.

The last item in the list of things to know is the one that settles the question for most people: this module works great in Windows PowerShell.

So the constraint is not a limitation to work around so much as a statement of scope. Testimo is a Windows administration tool that runs in the Windows shell, and PowerShell 7 support is a known gap with an open tracking issue rather than a promise.

## Installing and running it is three commands

The installation section is one command, and the author adds a note about why it is written the way it is.

```powershell
Install-Module -Name Testimo -AllowClobber -Force
```

Force and AllowClobber are not really necessary, but they do skip errors in case some appear. The module is published on the PowerShell Gallery, and the README carries the gallery version and download badges.

Updates have their own command:

```powershell
Update-Module -Name Testimo
```

Alternatively, rerunning Install-Module with force triggers a reinstallation or an update, and you may need to close and reopen your PowerShell session if you had already used the module before updating it.

The usage section shows the three shapes of invocation. The plain call writes to screen and to HTML:

```powershell
Invoke-Testimo
```

The -HideHTML switch generates all the tests but displays the content only in PowerShell, which is the one to use when you want the console output without waiting for the report.

And the form that matters for a real assessment selects a subset of sources, runs online, writes the report to a specific path and shows the steps:

```powershell
Invoke-Testimo -Source 'ForestOptionalFeatures','DomainWellKnownFolders','ForestSubnets' -Online -ReportPath $PSScriptRoot\Reports\TestimoSummary.html -AlwaysShowSteps
```

That last form is also the answer to a performance problem the README documents. There is a known issue that running all tests works correctly but the generated HTML is very very slow when switching tabs, and the advice is to run separate tests, which generate a smaller file and are more responsive.

## The configuration object is a hashtable you can edit before running

How you change the defaults is a decision the README explicitly leaves to you, because the configuration is a PowerShell hashtable and there are three routes to it.

Straight to file or JSON, which is the one for version control:

```powershell
Get-TestimoConfiguration -FilePath $PSScriptRoot\Configuration\TestimoConfiguration.json
```

Straight to JSON on screen:

```powershell
Get-TestimoConfiguration -AsJson
```

Or output to a hashtable that you can edit freely and keep in a ps1 file, which is the route the README shows in the non-default configuration example. The example imports the module, pulls the configuration, flips a couple of settings and selects a source list:

```powershell
Import-Module Testimo

$OutputOrderedDictionary = Get-TestimoConfiguration
$OutputOrderedDictionary.ForestOptionalFeatures.Tests.RecycleBinEnabled.Enable = $false
$OutputOrderedDictionary.ForestOptionalFeatures.Tests.LapsAvailable.Enable = $true
$OutputOrderedDictionary.ForestOptionalFeatures.Tests.LapsAvailable.Parameters.ExpectedValue = $false
```

The structure is a hierarchy of sources, each with tests, and each test with an Enable flag and a Parameters object holding the expected values. That shape is what makes the module useful rather than a black box: the expected value for a given check is data, so you can change what a check asserts without changing code.

The same example shows the two other capabilities in one place. A Sources array selects which sources run, and the ExcludeDomains parameter removes one domain from the run, which the README lists as one of the things a non-default configuration allows. The call ends with -PassThru, which returns the results so they can be processed further.

And the module is explicit that it comes with preset rules that may not apply to your environment, so you may want to disable some tests or change some values.

## The results can be returned, reported, or emailed

The module is designed to be a component in a larger pipeline rather than a terminal command, and the ReturnResults switch is the key to that.

```powershell
Invoke-Testimo -ReturnResults
```

The README says there are other parameters available with an option to be able to process the output, for example to email. The Example folder in the repository makes the same point concretely, with scripts named for the workflows they demonstrate: a quick test, external tests, split reports, custom tests, custom tests for Azure, a DSC comparison, an Active Directory test, an Active Directory test with a report, an Active Directory test by email, an Active Directory test by Word document, loading configuration from a file, loading configuration from a hash, and loading sources, plus an O365 folder, a Portable folder and a Configuration folder.

Two things stand out in that list. The email and Word examples mean the report is treated as a document that leaves the tool, not just a screen. And the DSC comparison examples suggest the output is meant to be diffed between runs, which is the natural way to use a health check over time: the same environment, run monthly, with the difference highlighted.

The examples are the documentation that matters here. The README says to be sure to check out the Examples section for more how-to, and given that the author says the function and file names are a mess that will be cleaned up later, the examples are also the more stable reference.

The repository layout supports that reading. The root has Testimo.psd1, Testimo.psm1 and Testimo.Tests.ps1, with Public and Private directories for the module code, a Tests directory, an Example directory, a Build directory, and a CHANGELOG.MD.

## Where Testimo is the wrong tool

The first wrong case is a PowerShell 7 environment, and that is not a preference. The module depends on GroupPolicy and ServerManager, neither of which is supported in PowerShell 7, and the tracking issue is still open. If your estate is cross-platform PowerShell, Testimo cannot run there today.

The second wrong case is a team that needs a stable configuration contract. The README says plainly that the configuration hash is not written in stone and can change rapidly, and that there is a big mess in file and function names with names still being invented. The author also warns that a small rename to a parameter can stop your code working, and advises keeping the version you know works until you have tested a new one on a test computer.

That advice is sound, but it means the module is something you pin and re-validate, not something you install once and let auto-update manage. A scheduled assessment job that upgrades itself is the arrangement the author is warning against.

The third wrong case is a one-off check. If you need to answer a single question about Group Policy replication or the state of one domain controller, running the relevant test and reading the console is faster than learning a configuration object, a source selection model and a report pipeline.

The alternative worth naming is a commercial Active Directory assessment tool, and the difference in approach is the difference between a script collection and a product. A commercial tool gives you a maintained test catalogue, a scheduler, baseline comparison and a support contract, at a price and with a vendor behind it. Testimo gives you the same shape of output for free, with the flexibility that you can read the checks and change them, and with the cost that the catalogue is one person's work in progress and the naming may change between versions. The trade is straightforward: if you want a report you can defend to an auditor and never touch again, the product is the safer buy. If you want to understand what is being checked and adjust the expectations to your own environment, a module you can read is worth more.

## Maintenance state, licensing and the update advice in the README

The repository is not archived, and the last push was on 2026-10-09, with v0.0.93 tagged the same day. The release cadence is worth reading: v0.0.90 came in September 2024, v0.0.92 in September 2026 and v0.0.93 in October 2026, so there is a two year gap followed by two releases in a month. That pattern fits a project maintained in bursts, and it is a reason to plan your upgrades around your own schedule rather than assume a steady stream.

The version numbering carries the message. v0.0.x means the author has not reached a stability promise, and the README says so in the same words, alpha product.

The licence is the one thing you should check directly. The project metadata lists it as unknown, and the visible repository listing includes a LICENSE file at the root. For a module you are about to install into a machine that holds Active Directory credentials, the terms in that file are the ones that matter, and the metadata field is not going to answer the question.

The final thing the README says is the one to internalise. The important thing is if something works for you on production, keep using it until you test the new version on a test computer, because the changes may not be big but are big enough that auto-update will break your code, with a small rename to a parameter given as the example. Be responsible is the instruction, and it is a reasonable thing for a maintainer to ask of a user of an alpha tool.

The project also points newcomers at a blog post about health checking Active Directory, and there is a blog at evotec.xyz. The author is Przemyslaw Klys, and the repository is EvotecIT/Testimo.

## Conclusion

Testimo fits a Windows administrator who needs a repeatable Active Directory assessment with a shareable HTML report rather than a pile of ad hoc commands. It is the wrong choice if you are on PowerShell 7, because the module depends on GroupPolicy and ServerManager and the issue tracking that incompatibility is still open, and it is the wrong choice if you need a stable configuration contract, because the author states that the configuration hash is not written in stone and can change rapidly. Before you adopt it, run it against a test machine first, keep the version pinned until you have validated an update, and read the Examples folder rather than assuming the parameter names are stable.

## FAQ

### How do I install Testimo?

Run Install-Module -Name Testimo -AllowClobber -Force from the PowerShell Gallery. The README notes that Force and AllowClobber are not really necessary but they skip errors in case some appear.

### Does Testimo work on PowerShell 7?

No. The README states that at present the module is not supported in PowerShell Core or PowerShell 7, because it depends on Microsoft modules that are also unsupported there, including GroupPolicy and ServerManager. Issue 110 tracks the compatibility work.

### How do I change the default Testimo configuration?

There are three routes: Get-TestimoConfiguration with a FilePath to write or read a JSON file, Get-TestimoConfiguration -AsJson for JSON on screen, or Get-TestimoConfiguration to get a hashtable you can edit and keep in a ps1 file. The hashtable has sources, each with tests, each with an Enable flag and Parameters holding expected values.

### Why are some checks missing from the Testimo report?

Sources and tests behave differently when requirements are not met. For a source, Testimo skips it totally from output. For a test, it marks it as skipped. This is listed under known issues as by design.

### Should I let Testimo auto-update in production?

The README advises against it. It says that if something works on production, keep using it until you have tested the new version on a test computer, because a change as small as renaming a parameter can stop your code working.

## Sources

- [EvotecIT/Testimo on GitHub](https://github.com/EvotecIT/Testimo)
- [Issues](https://github.com/EvotecIT/Testimo/issues)
- [README](https://github.com/EvotecIT/Testimo/blob/master/README.md)
- [Releases](https://github.com/EvotecIT/Testimo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/evotecit-testimo