-
-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[microsoft-teams-new-bootstrapper] Can we download the MSIX? #163
Comments
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 I don't think the chocolatey package could be versioned off of those though. |
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. |
Those links resolve to
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. |
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" /> |
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. |
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 If I'm misunderstanding something, feel free to explain (or not) and I'll shut up. |
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. |
The "two package" solutions is just in preview, so now is a good time to discuss if it makes sense or not. Feedback welcome! |
@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. |
@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. |
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 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. |
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" |
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. |
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. |
Found a published Teams client version history here - https://learn.microsoft.com/en-us/officeupdates/teams-app-versioning?WT.mc_id=DOP-MVP-5001655#windows-version-history The current MSIX download version is 23320.3021.2567.4799 which doesn't match any of the recent Windows versions, but seems to be between the two December releases
The 4th number does change, so that is promising |
I work for Microsoft but I do not work on the Microsoft Teams engineering team.
Its main purpose is to bulk deploy the new Teams so there could be unattended side effects for using it for downgrading and upgrading your Teams 2.1.
Those URLs will always point to the Last Known Good (LKG) installers, and they are only updated to newer versions depending on our telemetry in different cloud environments such as Public Cloud, GCC, GCC High, DoD, and Gallatin. There are essentially three release states:
As of today for Ring 4 - all three are the same now:
I could create an aka.ms URL just for Chocolately to always download latest GA version of Teams 2.1 instead of the LKG version but that requires manual work from my side as well as setting up automation to make sure the aka.ms URLs are continuously updated to always point to the latest GA version of Teams 2.1.
You can just parse the JSON from https://config.teams.microsoft.com/config/v1/MicrosoftTeams/49_1.0.0.0?environment=prod&audienceGroup=general&teamsRing=general&agent=TeamsBuilds to get the latest build version for Teams 2.1, and then make a version-specific URL by replacing A lot of what you see in the JSON is used by Teams 2.0 and Teams 2.1 where it periodically checks for updates for the frontend (WebView2) and for the backend (React Web Client + CDL Worker).
That is what powers Microsoft Teams under-the-hood as well as what I am currently doing: https://raw.githubusercontent.com/ItzLevvie/MicrosoftTeams-msinternal/master/defconfig2 Regarding
It is very unlikely for this to happen on our public release trains but it does happen to our internal release trains especially between Windows and macOS. Those internal release trains are on our internal environment which is separated from our production environment so if you really wanted to do this then there will be zero issues and zero versioning conflicts between public release trains and internal release trains.
I have taken a look at your OneDrive package, and it looks like most of the issues stems from scraping build versions from support.microsoft.com which closely resembles what is happening on Microsoft Docs. See https://www.reddit.com/r/sysadmin/comments/11tr33k/onedrive_build_newer_than_production_ring_build/ When the go.microsoft.com links change that is mostly down to our engineers because manual work is required to keep the links updated. Sometimes our engineers will update the same go.microsoft.com link to point to the latest version, and other times our engineers will create a brand new go.microsoft.com link to point to the latest version. Some go.microsoft.com (and aka.ms) links have automation in place to make sure that these types of errors are as close to zero as possible. I feel like it would be much better to use solutions from aaronparker/evergreen#268 (comment) since that is automatically updated from our flighting system and will result in much less errors.
We use the As an example - There is a lot more to this such as the usefulness of the 2nd part number ( We use the As an example - We have two build flavors for Teams 1.0. One is
A lot of the Microsoft Docs pages, including the ones for Windows and other Microsoft products, are usually delayed by a few days to a few weeks because of priority work so some build versions will be missing. Reliability on these pages for scripting purposes are not always guaranteed to work due to typos which tend to happen from time-to-time but sometimes those are quickly fixed before we receive complaints from consumers and commercial customers, and sometimes those typos will be unnoticed by our engineers (or copywriters) where those typos would stay there for a weeks to a few months to a few years until someone spots the error and makes a pull request to fix that. |
Thanks @ItzLevvie for that detailed info. That will be helpful in figuring out a version for the package. |
I've just published a preview version of a combined package - https://community.chocolatey.org/packages/microsoft-teams-new-bootstrapper/1.0.2402201.24004-pre. The version number uses the first 3 parts of the bootstrapper version and the first component (the YYDDD bit) of the Teams 2.1 Enterprise version.
Questions:
thanks! |
Mind if I pitch in on point 3. I would suggest to also update on MSIX releases. Getting the version from the file should be fairly straightforward in Chocolatey. Set-Alias -Name 7z -Value $Env:chocolateyInstall\tools\7z.exe
7z e <msixBundle> AppxManifest.xml
[xml]$manifest = get-content .\AppxManifest.xml
$version = $manifest.Package.Identity.Version |
@ItzLevvie do you happen to know if there are version-specific URLs for teamsbootstrapper.exe? I'm not sure if there's inconsistencies in the CDN, but while working on updating this package, I noticed I'm getting different versions being offered when hitting https://statics.teams.cdn.office.net/production-teamsprovision/lkg/teamsbootstrapper.exe - sometimes the older version, sometimes the newer one. Obviously this doesn't play nice with Chocolatey's requirement to compare a checksum hash. |
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
The text was updated successfully, but these errors were encountered: