Recommended winget strategies for LOB distribution

[bayko]

First off thank you to the team working on this project and making it open source for community contributions very early into it's development. With the announcement that the windows store ecosystem will be sunset in the first quarter of 2023 I'm sure there are many organizations out there relieved to see a project like this in the works to serve as an alternative.

Initial deployment of the private repository was a little tricky, but I fully understand this is a work in progress and the process/documentation will improve over time. Once the API was deployed everything seems to work very well out of the box (and can definitely see the appeal of how easy it is to pull software down onto machines with Winget).

Now were trying to imagine how this private repository could potentially be used as a replacement for the Windows Store LOB distribution channels. A key feature of the store LOB distribution is the ability for publishers to have a single catalogue of software packages, but control individual package assignments to their partners. For example if the publishers catalog has 3 software packages in it total, all 3 packages might be assigned/available to one connected partner, but another partner may only have access to 1 or 2 of those titles out of the catalogue.

Testing with the private repository we can see its simple enough to control access to the api endpoint itself and the underlying storage for each package installer. Where there is uncertainty right now is simply what is the best practice/recommended way to try and achieve this (or if this is a bad idea to try entirely?). We have been working with @mjfusa from the app consult team at Microsoft to try and plan our impending transition, and it was suggested to post our situation here as this team has the most expertise with private repositories and would have a better idea of any development plans in the coming year.

Currently were able to think of 2 (potential?) approaches to take and trying to work out if either would be manageable.

Approach 1

Each partner deploys their own private API endpoint and controls access to their users how they see fit. The publisher maintains a separate storage account for each partner, and a master storage account containing all of their package installation media. To assign a package to a specific partner, the package is synced from the master storage to the partners storage account and a manifest is pushed to the partners private repository with reference to the installer location in their specific storage location.

pros

• partners are only able to see software titles that they can actually install
• access can be revoked by removing the manifest and installer out of the partners system
• each partners endpoint/storage could be secured in a way that suits the partner

cons

• if there are more than a handful of partners this could be a lot of infrastructure to manage
• the partner needs to supply access to their azure tenant for the publisher to deploy the infrastructure (unless its all deployed in publishers tenant)
• some development required for automation of process

Approach 2

The publisher creates a single private API endpoint (all partners have access), storage accounts for each partner, and a master storage account containing all installers. To assign a package to a specific partner, the installer is synced to that partners storage account, and a unique package manifest is added to the repository with reference to it.

pros

• only requires management of a single api endpoint
• each partner storage could be secured in a way that suits the partner

cons

• partners would see all programs in the repository, installations would fail on anything not assigned.
• software packages might need to use partner specific aliases which could be confusing to users trying to install something
• some development required for automation of process

Approach 3

Is there something we are totally looking over right now that could be done at the individual manifest level, or somewhere else to easier control access? For example maybe having redundant installation locations in a manifest which are partner specific?

Would be grateful for any suggestions or advice you can provide in this area. Unfortunately at the moment things are largely undocumented so just want to try and ensure we are not going down the wrong path in the coming months. As the deadline for the store going away gets closer, the urgency to find an alternative will definitely keep ramping up.

Thank you again!

[denelon]

@bayko thanks so much for taking the time to write all of this out! I'm going to convert this to a discussion rather than an Issue. I think this is something we should continue having an open dialogue on. There are several approaches we have been considering for private sources and "authorization/authentication" mechanisms.

[denelon]

One of the areas we're investigating is the right kinds of business scenarios to prioritize with the implementation. Our current largest effort is related to the Microsoft Store source for the Windows Package Manager. We're expecting this to help inform us on the right ways to scale, and to handle the exact concerns you mentioned. We will also be looking at how the Intune integration evolves.

We have plenty of work associated with authentication for paid apps in the Microsoft Store. We are also working on an Arbitrary HTTP header that can be used to drive custom behaviors with a REST source. Our hope is that this enables completely custom behaviors, and as we see different common use cases, we can bring those into being first class scenarios. I suspect some of what you suggested will fall into that category.

[bayko]

@denelon really appreciate you taking the time to thoughtfully respond, and for keeping this open to further discussions going forward. I understand this is a massive project with many development teams working on the many different systems needed to bring it all together and that you won't have all of the answers for us. I think at this stage it is mainly uncertainty around the 2 q&a points mentioned in the article you linked that are the source of some confusion on a hosted solution offer in the future.

Q: Can my end users access my local private app repository from the Store?

A: You will be able to provide your end users access to your local private app repository via Company Portal on Microsoft Endpoint Manager or your UEM solution. The Store will no longer show private, organizationally curated applications.

Q: I am currently using the Store for private line-of-business apps built by a software vendor or in-house developer. Will those continue to work in the new solution?

A: Line-of-business apps will need to be migrated to your local private app repository before the retirement of the Microsoft Store for Business in Q1 2023. We will provide more details on how to do this migration for you and your ISV in the near future. Apps that have already been assigned and deployed to endpoints will continue to work after the retirement of the Store for Business as long as they are not removed from the device.

I guess we will just need to be patient for now until the time comes that more information is shared on the planned migration strategy as the post mentions. However after being directed to this API project by several people I was starting to take this as a hint that LOB vendors might need to look at building out their own delivery channels through winget private repositories. If this is not the case and Microsoft are going to continue with some kind of hosted solution for vendors, I think this would definitely be preferable for a lot of organizations compared to a custom in-house solution.

I am hopeful that we will start getting some more information from Microsoft in the coming weeks/months!

Thanks again

[myokeeh]

I still feel like there is no succinct guidance for a small company like ours (NOT able to implement Intune).

I am at the point that I have a code signing certificate and have been able to test it out a bit, but still unsure about the best practice for distributing our LOB apps.

Currently, I think I have the following options, but wanted to see which way to go.

• Publish the LOB apps via Visual Studio with our code-signing cert and have it auto update via MSIX functionality.
• Setup a private repository and use winget to install and update apps.

First, I am unsure if there are overlaps or flexibility in going with the first then having the option of moving on to making a private repository.

Already, in the process of getting a code-signing cert, I discovered that the Publisher ID for my apps is now different compared to the Microsoft Store signed version,it appears there's no continuity in the apps already deployed to our workforce vs the ones I'm now code signing. The apps appear to get installed side by side and not get updated. Are there similar issues with Winget/Private Repository?

I think I read somewhere that the MSIX auto-update mechanism doesn't allow for any authentication, so I can't put the updates/installers behind a location requiring sign-in.

I think it's still a little vague to me how the auto-updating works with winget. Is that truly automatic? How often does it check? Can it be defined for each app?