Windows Protocol Test Suites: checking an implementation against the specification

What the suites are for, and what they are not

The Windows Protocol Test Suites provide interoperability testing against implementations of Windows open specifications, including File Services, Identity Management and Remote Desktop. They were originally developed for in-house testing of the Microsoft Open Specifications and have been used extensively during Plugfests and interoperability labs to test against partner implementations. A Test Suite evaluates whether a protocol or protocol family implementation meets certain interoperability requirements. The caveat is stated in the project overview and is worth repeating exactly in substance. Test Suites do not cover every protocol requirement, and in no way do they certify an implementation, even if all tests pass. What each suite gives you is a useful indication of interoperability, and that framing matters when you read a report from one.

The families covered, and where the specification documents sit

The suite list is organised by protocol family, and each entry names the specific open specifications it exercises. The File Server Family Test Suite covers the file server protocol family including MS-SMB2, MS-DFSC, MS-SWN, MS-FSRVP, MS-FSA, MS-FSCC, MS-RSVD and MS-SQOS. The RDP Client Family Test Suite covers the client side of the RDP family including MS-RDPBCGR, MS-RDPEDISP, MS-RDPEDYC, MS-RDPEGFX, MS-RDPEGT, MS-RDPEI, MS-RDPEMT, MS-RDPEUDP, MS-RDPEUSB, MS-RDPEVOR and MS-RDPRFX, while the RDP Server Family Test Suite covers the server side including MS-RDPBCGR, MS-RDPEDYC, MS-RDPEMT and MS-RDPELE. The Kerberos Server Test Suite covers MS-KILE, MS-KKDCP and MS-PAC. The ADFamily Test Suite covers the Active Directory protocols including MS-ADA1, MS-ADA2, MS-ADA3, MS-ADLS, MS-ADSC, MS-ADTS, MS-APDS, MS-DRSR, MS-FRS2, MS-LSAD, MS-LSAT, MS-SAMR and MS-NRPC, and there are also suites for Branch Cache, AZOD, ADOD, ADFSPIP, XCA and WSP, plus an SMBD Server suite for SMB2 and SMB3 direct over RDMA.

The four components, and which one you actually use

The repository is split into four components, and understanding the split tells you where to look when something goes wrong. CommonScripts holds the common scripts used by each test suite, and they are normally used to deploy the environment. ProtoSDK is the protocol library used by each test suite, providing the data structures of the protocol messages, the methods to encode and decode them, and the methods to send and receive them. TestSuites holds all the test suite code and documents, categorised by folder, one folder per suite. ProtocolTestManager is the tool that helps you configure and run the suites. In practice the flow is that the manager points at a suite, the suite drives the implementation under test using ProtoSDK to speak the protocol, and CommonScripts have set up the machines, accounts and certificates that make the exchange possible.

Preparing a test environment, including the disposable Azure option

The suites need somewhere to run against, and the project provides a way to make that disposable. For the File Server suite there is a File Server Azure automated deployment described in the repository, and it exists specifically so you can create a disposable Azure test environment rather than provisioning your own. That matters more than it first appears, because the protocol suites need specific machine roles, and a fresh environment per test run is what makes a test result mean anything. The same document links a per-suite user guide for every family, covering the File Server, RDP Client, RDP Server, Kerberos Server, SMBD Server, Branch Cache, AZOD, ADFamily, ADFSPIP, ADOD, XCA and WSP suites, and the guides are where the actual procedure lives rather than the overview.

Prerequisites, and the .NET base

The suites are based on .NET so they can be developed and run across different platforms, and you should install the software listed for your testing purpose along with their own dependencies. The baseline is the .NET 8.0 SDK on Windows, Linux and macOS, for building or running the test suites. For those who work on Windows and prefer an IDE, the recommendation is Visual Studio 2022 or higher, with the Community edition recommended, and the documentation then lists which individual components of the installer are required to run the suites and which are required to build them from source, in a table that separates the .NET SDK and the compilers. The repository also ships an InstallPrerequisites directory, which suggests the prerequisites are scripted rather than left as a manual checklist.

The repository today, and how it is worked on

The last push to the repository was on 2026-10-18, and the release history shows a steady four-week-ish cadence, with 4.26.9.0 on 2026-09-02, 4.26.8.1 on 2026-08-12 and 4.26.8.0 on 2026-08-05. The top level is larger than a test suite repository usually is, and the directory names explain why. There is an .azuredevops directory for the build pipelines, a RemoteRun directory, a MessageAnalyzerLibrary, a diffs directory, an ai-docs directory and a common directory, alongside the four core components and the InstallPrerequisites and Doc directories. The presence of a diffs directory and a CLAUDE.md file points to a project that is being worked on with tooling assistance and that keeps some notion of what changed between protocol revisions, which is what you would expect from a suite that has to follow the open specifications as they are revised. The project also points at an events page for interoperability labs, and the repository description carries the announcement of the next one.

Editorial conclusion

Windows Protocol Test Suites fit a vendor implementing a Windows protocol family and who wants to know which behaviours their implementation gets wrong, since the suites are the same harness Microsoft used in house and at plugfests and labs, and they fit an implementer preparing for an interoperability event. They do not fit a developer building a client that only has to talk to Windows, because the suites are for the implementation side and they are heavy, and they do not fit anyone who wants a pass or fail certification, because the project states that the suites do not cover every protocol requirement and in no way certify an implementation even if all tests pass. Before you start, read the user guide for the specific suite rather than the overview, and plan the environment, since the common scripts normally deploy the test environment and the Azure automated deployment exists to make that disposable.

Frequently asked questions

Official sources

1. Issues
2. microsoft/WindowsProtocolTestSuites on GitHub
3. Project website
4. README
5. Releases