MicrosoftTeams-msinternal: fetching internal Teams builds and decoding their version numbers

A build repository, and an honest warning about its own docs

This project was created from PowerShell and it allows people to download the latest internal build of Microsoft Teams, and the readme opens with a warning that is worth taking at face value. The README.md file has not been updated for nearly a year or more and may contain inaccuracies. That statement sits at the top of the file, above everything else, and it changes how the rest of the documentation should be read. The repository is not archived and the last push was on 2026-10-20, so the tooling is alive even where the prose is not, and that gap between a maintained script and a stale document is the single most important thing to know before you spend an afternoon on it. The default branch is master, the primary language is PowerShell, and the project publishes no GitHub releases.

The two configuration files, and what they cover

The repository contains several files, and the two at the top are the ones that matter. The defconfig file shows the daily builds, the experimental builds, the preview builds and the public builds for Microsoft Teams classic. The defconfig2 file shows the builds in all rings for Microsoft Teams classic, for Microsoft Teams personal, for Microsoft Teams, and for Microsoft Teams Rooms. The split is the interesting part, because the two generations of the client are not the same thing. Teams 1.0 is the classic client built on Electron, on versions 22.3.27 and 31.7.7. Teams 2.0 is Microsoft Teams personal built on Microsoft Edge WebView2, and Teams 2.1 covers both Microsoft Teams and Microsoft Teams Rooms on WebView2. The source code itself is two files, a src/Get-MicrosoftTeams.ps1 script that fetches the latest builds in different environments and different rings, and a launch script under tools/ that lets you create your own RELEASES file, so you are not stuck with the configuration that ships in the repository.

The build rings, and what the flags in the menu mean

The FAQ section defines the rings, and the definitions are about how much risk you are taking rather than about dates. Daily builds preview the latest development builds of Microsoft Teams, and they may also contain newer versions of SlimCore. Experimental builds preview the latest development builds but with access to new ideas which may or may not ship into daily builds, and those may also contain newer versions of SlimCore. The difference is visible in the application itself, because an experimental build displays an -E in the three-dot menu under About and Version. On the WebView2 generation the rings are named differently, with Canary builds being the R0 ring and Canary SlimCore builds being the R0s ring, and the R0s variant exists to preview newer versions of SlimCore specifically. A note in the readme adds the caution that matters for expectations, since installing these builds does not necessarily mean you will have access to new features.

Reading a Teams 1.0 version number

The readme spends a lot of its length decoding version numbers, and it is the part of the documentation most likely to still be accurate, because the scheme does not change. The format for Teams 1.0 is 1.X.00.DDDXX, and the example given is 1.7.00.4065. The X is the year of the build, with 8 representing 2025, 7 representing 2024, 6 representing 2023, and so on down through 0 for 2017, which is a countdown rather than a normal year field. The DDD is the day number of that year, with 40 representing Friday, February 9, 2024, and the two fields are consistent with each other, since 2024 was a leap year and the fortieth day of it is that Friday. The final XX is automatically generated by Azure DevOps, so it carries no date information. The readme also explains the two build flavours encoded in the last two digits, with a version ending in 51 to 99 being a stable build and one ending in 1 to 49 being experimental.

Reading a Teams 2.0 version, and forcing a client version

The newer generation uses the YYDDD.XXXX.XXXX.XXXX format, and the example is 24041.300.2689.9173. The YY is the year and the DDD is the day of that year, so 24 is 2024 and 041 is Saturday, February 10, 2024, and the two Azure DevOps generated fields follow, with one of them being the amount of builds created excluding servicing builds, which is the number that tells you how often the team was integrating. The separate React Web Client has its own format, XXXX/YYMMDDXXXXX, where the first number is the platform ID, the next six are the year, month and day, and the last five are Azure DevOps generated. Microsoft Teams supports a version parameter, which allows you to force different versions of that client, and the readme gives three examples, one on teams.live.com with a ring0 parameter, one on teams.microsoft.com with a ring1_5 parameter, and one on devspaces.skype.com with a ring0 parameter.

The platform ID table, and the feedback routes

Platform IDs are used by Microsoft Teams to differentiate platforms for flighting, telemetry and more, and the readme gives a table with the friendly name for each. The numbering is not arbitrary in appearance. The 27 range covers Microsoft Teams classic based on Electron, on Windows and then macOS, the 34 and 35 entries cover Microsoft Teams Rooms on Windows and classic for Surface Hub, and 41 is classic on Linux. The 48 to 51 range covers the WebView2 generation, with Microsoft Teams personal on Windows, Microsoft Teams on Windows and macOS, and Microsoft Teams Rooms on Windows. The friendly names in that table are the same words the version format section uses, so a build number alone tells you both the generation and the platform it is for. Separately, the readme points feedback in two directions, to a public feedback portal for Teams personal and to a separate public portal for Teams, plus private portals only available to Microsoft employees for each.

Editorial conclusion

This repository fits someone who needs to install a specific internal Teams build, in a given ring, on Windows or macOS, because the defconfig files and the fetch script exist for exactly that, and it fits anyone who has to reason about which build a colleague is running from a version string. It does not fit an ordinary Teams user, since the builds it fetches are pre-release and may not give you the features you are hoping for, and the project says so in a note pointing at a blog post on the release process. It also does not fit a reader who assumes the documentation is current, because the readme carries a caution that it has not been updated for nearly a year and may contain inaccuracies. Before you rely on any of it, read the version decoding section against a build you already have, and treat the internal rings as a preview environment rather than a supported one.

Frequently asked questions

Official sources

1. Issues
2. ItzLevvie/MicrosoftTeams-msinternal on GitHub
3. README