[microsoft-teams-new-bootstrapper] Can we download the MSIX?

[flcdrg]

The bootstrapper.exe can download the MSIX. Is it possible for chocolateyInstall.ps1 to do this instead?

https://learn.microsoft.com/en-us/microsoftteams/new-teams-bulk-install-client#option-1b-download-and-install-new-teams-using-an-offline-installer

[QuimaxW]

My hunch is that these links will be stable to the current version of the msix, regardless of it's version on a given day.

x86: https://go.microsoft.com/fwlink/?linkid=2196060&clcid=0x409
x64: https://go.microsoft.com/fwlink/?linkid=2196106
ARM64: https://go.microsoft.com/fwlink/?linkid=2196207&clcid=0x409

I don't think the chocolatey package could be versioned off of those though.

[QuimaxW]

Redistribution rights shouldn't be an issue as the machine installing the package is pulling everything from Microsoft's servers at the time of install. Only folks who are internalizing the package for their organizational use would need worry about redistribution. However, as Microsoft has instructions for doing exactly that, it's being expected in that scenario that the redistribution is happening.

Another workaround for my case would be that we build a custom package for this that would have everything in the package.

[flcdrg]

Those links resolve to

• https://statics.teams.cdn.office.net/production-windows-x86/enterprise/webview2/lkg/MSTeams-x86.msix
• https://statics.teams.cdn.office.net/production-windows-x64/enterprise/webview2/lkg/MSTeams-x64.msix

Those URLs at first glance don't look like they probably change when the binary files change, which is disappointing. Will have to take another look when a new version is released.

[flcdrg]

For reference, the AppManifest.xml file inside the x64 msix contains this, which might be useful as a version marker.

  <Identity Name="MSTeams" Version="23320.3021.2567.4799" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ProcessorArchitecture="x64" />

[flcdrg]

A new version of the package was generated overnight. Interestingly the msix files haven't changed (and are a bit outdated compared to the version of Teams I have installed locally).

I'm going to create a separate package for the MSIX files, with the intention that this package can depend on that one.

[flcdrg]

Interesting to compare the bootstrapper version numbers to the ones reported in Teams.

[teknowledgist]

Maybe this is an ignorant comment, but I don't understand why the bootstrapper and MSIX are separate Chocolatey packages. The goal here is to have a known version of (New) Teams installed, right? Do either of the bootstrapper or MSIX make it possible to know which version of Teams is ultimately installed?

If not, then is it even possible to know there is a one-to-one match between the Teams version and either of these download versions? How can we know what version of Teams, Chocolatey will be installing?

If the Teams version can be identified, then why not just make the package download both the bootstrapper and MSIX files and keep the package management simple? The chocolateyinstall.ps1 code might not be so simple, but the user will have a lot less confusing time of tracking it. Look at the Adobe reader package, for example. It might have to download/install the "base" version and then an updater, or it might just need to install the updater. In the end though, the user doesn't need to worry about all that.

If I'm misunderstanding something, feel free to explain (or not) and I'll shut up.

[flcdrg]

It is a good question and one I thought about (and one that could be reversed in the future). I decided to go with separate packages as the two parts do seem to be versioned separately, and updated on a different schedule.

Even then, the MSIX downloads don't always appear to be the latest version that you can get if you check for updates within Teams, but maybe Microsoft are just being a bit conservative when they update the download URLs.

Also worth noting - this package is only good for pre-installing Teams on a machine the first time.. It isn't any good for updating Teams once you are using it (as far as I know). So the choco version numbers would also quickly be outdated once the client starts self-updating.

[flcdrg]

The "two package" solutions is just in preview, so now is a good time to discuss if it makes sense or not. Feedback welcome!

[QuimaxW]

@teknowledgist - My goal was to have a self-contained package that would internalize properly and not require a separate download which would slow down deployments. This would also have a benefit of bringing in a fairly current version of Teams as well.

However, as @flcdrg mentioned, unless one has a way of turning off the auto-updating of Teams, this package becomes quickly out of sync with Microsoft's versions. Just keeping with the current version could be a full time job to do it manually. We'd need a script that would download the bootstrapper and the msix, extract the version number, update the nuspec file(s), and upload those back to the community repo on a near nightly basis.

What I'm likely to do for our internal repo is have a script run weekly to pull the MSI file down to a local http server. Use the bootstrapper package, modified to use this http location as the source for the MSIx. This would follow the same model we use for Office365, where the package version is only bumped when we need to force a reinstall of the product.

[flcdrg]

@QuimaxW I don't use Chocolatey for Business, though I have heard of the internalising stuff. Does the internalising thing mean you'd prefer a single package, or is having two packages fine?

As far as I know, this "install it just once" is pretty much the same behaviour as the old Teams Enterprise installer. Once the bits are on the machine then Teams will self-update for each user on that machine.

[teknowledgist]

That Chocolatey package versions can be used "just for install" and the app upgrades itself is not terribly unique. Look at Firefox or Chrome. I do think Teams is different from those in that the self-updates are per-user.

The "Old Teams" enterprise installer was actually an installer-installer. It would install the per-user installer so that said installer would run on login of each user. The per-user installer would either install Teams or would upgrade Teams, but the Chocolatey package version would still match the enterprise installer version. I don't know if the per-user installer would install the "installed" version on first run and then update to the latest (whether immediately automatically, immediately if incompatibilities were discovered, or the next time the user logged in) or would download the latest version to install. I do know that the "install on login" slowed down new user logins and was tremendously annoying in classrooms and labs where Teams might be wanted, but only on demand. The per-user nature of it also meant that a choco uninstall would only remove the "installer-installer", but all existing user profiles would continue to have (and update) Teams.

I am assuming the "New Teams" installer is a similar kind of bastard, and thus, I still think the package should be focused on the version of Teams that will result on a clean install (i.e. first login). I should clarify that to the version of Teams before it updates itself. For example, the version of Teams that a new user would see if there was no Internet access for Teams to update itself. Like "Old Teams", the version any user has/uses will not match the Chocolatey package version, but the "primed" installer should continue to match the Chocolatey version.

My issue with having two packages is that they each seem meaningless without the other. Who cares if they have version xyz of the bootstrapper (or MSIX) if they don't know what version of Teams will result from a fresh install of it? How are you going to know what versions of the two downloads are compatible with each other? I think a "mono-package" is better for internalizing too. You are basically "freezing" the installer version and don't need to worry about the versions of the individual downloads.

As for how you determine the version of Teams to name/version the package... I don't know. MS is really terrible about some software download and/or versioning. I have to troubleshoot the OneDrive package all the time because they change the URL without changing the version or the reverse, or sometimes change both without updating the announcement page.

Anyway, that's my $.02. Thanks for the discussion opportunity.

[flcdrg]

You're bringing me around to the idea of having a single package - but yes as you hint at, then the question is, how do I version that package?

The MSIX version seems like it would be useful (as it corresponds with what you'd see in the UI - see screenshot above), but it is already a 4-part version, so there's no way to safely increment it when a new bootstrapper.exe was released but the MSIX was not updated.

The version numbers is probably the stumbling block to having a "mono-package"

[teknowledgist]

I suspect it is unlikely that the bootstrapper would update without the MSIX changing. However, given that this IS Microsoft...

OneDrive is also a "full", 4-part version, so when MS plays their three-card monte game and changes download URLs without changing the version (or other disorganization), I just add one to the last number. I don't know any software anywhere that both uses a full version number AND releases single increments on the last number. Take your example above. How likely is Microsoft to release version 23320.3027.2591.1506 after version 23320.3027.2591.1505? There is no Chocolatey rule that says the package version has to match the software version except for a possible date string in the build version slot.

[flcdrg]

Unfortunately Microsoft have done just that. The MSIX was last updated early December, but bootstrapper was updated as recently as a week ago.

The date string in the build version slot is an interesting idea. It would be helpful to see how Microsoft do change the MSIX versions over time. If they always rev the 3rd number, then we could mess with the 4th safely.