CSS-Exchange: Microsoft's toolbox of diagnostic scripts for Exchange Server

A repository that is a collection of tools, not a library

The CSS-Exchange repository is described as the home of several scripts for Microsoft Exchange Server and Exchange Online. The scripts are intended for identifying and resolving a wide range of issues that impact on-premise or hybrid deployments and migrations.

That framing sets expectations correctly. There is no package to install, no module to require and no API to call. The repository is a set of PowerShell tools, and the primary language of the project is PowerShell. What you do with them is read them, and run the one that matches the problem in front of you.

The audience is narrow and identifiable: the administrator or consultant who is running an Exchange deployment, on-premises or in a hybrid topology, and who is somewhere in a migration. The problems it targets are the ones that are hard to diagnose from first principles, which is exactly what a support organisation accumulates over years of escalations.

Two supporting details say the project is a working support operation rather than a side project. The README carries a download statistics badge pointing at the latest GitHub release, which is what you would expect for tools people download rather than install. And the per-script documentation is published on a separate site, microsoft.github.io/CSS-Exchange, with a link from the repository, which means the README is a signpost and the site is the manual.

The folder names are the index

There is no table of scripts in the README, so the directory structure is the discovery mechanism, and it is worth reading as a taxonomy of the problems the scripts address.

The top level groups the scripts by area rather than by Exchange component. There are Admin, Calendar, Databases, Diagnostics, Hybrid, M365, Outlook, Performance, PublicFolders, Retention, Search, Security, Setup, Shared and Transport, alongside the infrastructure directories .build, .github and .vscode, the docs directory, and the mkdocs.yml that drives the documentation site.

That grouping tells you something about how the scripts are meant to be consumed. A script about a stuck mailbox belongs to the Outlook group, a script about delivery belongs to Transport, one about an upgrade belongs to Setup, and one about search indexing belongs to Search. The grouping is by the operator's symptom rather than by the server role, which is the right axis for a support tool, because that is how the person using it is thinking.

Two directories deserve a note. Shared is where the common code lives, so the scripts in the other folders are presumably built on shared helpers rather than each reimplementing connection handling and reporting. Setup is the group that deals with the environment itself, which for an on-premise deployment is where most of the risk sits, because the difference between a supported and an unsupported topology is a configuration question.

Hybrid, M365 and Databases are the directories that tell you where the project concentrates today. Hybrid covers the on-premises to Exchange Online boundary, M365 covers the cloud service, and Databases is the part that is hardest to get wrong.

Linting and documentation are first class in the tree

Two files in the repository reveal how the project is maintained, and both are things you would not find in a scripts dump.

PSScriptAnalyzerSettings.psd1 is a configuration file for PSScriptAnalyzer, the PowerShell linter. Its presence at the root means the scripts are held to a static analysis standard, which for a repository whose scripts run with administrative rights on a production server is not a small detail. A script that reads mailboxes, moves mail or rewrites configuration is only as trustworthy as the code that produced it, and a linter is the cheapest way to catch the class of mistake where a variable is used before it is set or a parameter is misspelled.

The documentation is a site rather than a folder of Markdown files. There is a docs directory and an mkdocs.yml, and the README points at microsoft.github.io/CSS-Exchange for the documentation of individual scripts. So each script has its own page, and the repository is the code while the site is the manual.

Then there is the pipeline. azure-pipeline-merge.yml sits at the root, and the build status badge in the README points at an Azure DevOps pipeline on the release branch, named for the CSS Exchange Tools organisation. A merge pipeline on a release branch is a release engineering arrangement, and it explains the third fact: the version numbers.

Version numbers that encode the date they were built

The release tags are unusual and useful at a glance. The recent ones are v26.10.13.1709 from 2026-10-13, v26.10.02.1939 from 2026-10-02 and v26.09.22.1510 from 2026-09-22.

Read the first three components as a date: year, month and day. The tag v26.10.13.1709 was published on 13 October 2026, and v26.09.22.1510 on 22 September 2026. The fourth component, 1709, 1939 and 1510, is a time of day, which is the build time in the same local format. So the version is a timestamp, and a support engineer comparing two builds can tell from the string alone which one is newer, without a changelog or a release note.

That is a deliberate choice for tooling that gets copied around and run against different environments, where knowing exactly which revision you ran is often the difference between reproducing a problem and not reproducing it.

The cadence visible in these three tags is three releases in three weeks, which is a useful signal for an adopter: the project is being updated on a short cycle, and the pull request merge pipeline on the release branch suggests those updates are gated by review rather than published straight from a branch. The last push to the repository was on 2026-10-19, so the work is current.

Running these scripts means running someone else's code on your server

There is a property of this project that has nothing to do with code quality and everything to do with what the scripts do.

These are administrative scripts. They query and modify an Exchange deployment, which in an on-premises environment means they run with whatever rights the operator grants them, against a mail system that a business depends on. The risk profile is not the same as running a linting tool or a converter, and the failure mode is a broken production server rather than a failed script.

That has a few concrete consequences. The documentation site per script is the place to check what the script touches, what it expects to find and what it changes, and the README is explicit that more information is available there for individual scripts. And the scripts are copies, not references: you download a version, you read it, and you run it. You are responsible for the version you ran, which is why a date-encoded version number is a genuinely useful property here rather than a curiosity.

The alternative to running a support script is writing your own query and reasoning about the output yourself. The difference in approach is where the value sits. A script encodes a triage path that has been walked many times before yours, which is worth a great deal when the problem is unfamiliar and the window for recovery is small. Your own script is tailored to your environment and to exactly the question you have, and it carries the cost of writing the logic, the edge cases and the interpretation.

Neither is better in general. What is worth saying is that the support script trades flexibility for a known path, and that the trade is only a good one if you read the script before you run it.

Contribution comes with a CLA, and so does the code of conduct

The contribution rules are documented in the README rather than only in a contributing file, which is a sign of how seriously the project treats them.

Most contributions require you to agree to a Contributor License Agreement declaring that you have the right to, and actually do, grant the rights to use your contribution. When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the pull request appropriately, and the instructions say you will only need to do this once across all repos using the Microsoft CLA.

The practical effect is that contributing to this project means agreeing to Microsoft's terms for intellectual property, which is a normal arrangement for a corporate open source project and different from a plain MIT contribution. Anyone who is not in a position to sign such an agreement can still use the scripts, which is the part the licence governs.

The project has also adopted the Microsoft Open Source Code of Conduct, with a link to the code of conduct FAQ and a contact address, and the repository carries a SECURITY.md for reporting issues, a CONTRIBUTING.md, and a CODE_OF_CONDUCT.md at the root.

The licence for the code itself is MIT, with the LICENSE file in the repository. The governance around it, a CLA, a code of conduct and a security policy, is the part that makes this a project run as a support organisation rather than a personal repository, and it is the reason the download badge and the release pipeline exist at all.

Editorial conclusion

CSS-Exchange fits an Exchange administrator facing a specific, named problem on an on-premise or hybrid deployment, and who would rather run a script the vendor wrote and tested than reconstruct the diagnostic steps. It does not fit a team that wants a managed dependency, because there is nothing to install and nothing to version, and it does not fit an Exchange Online only shop, where most of these scripts do not apply. Before you run anything from it, read the script's own page on the documentation site, and check the version and the environment the script expects, since each one runs against a live server.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/CSS-Exchange on GitHub
4. README
5. Releases