Microsoft is in the process of changing how businesses use the Microsoft Store, as it brings its Package Manager tooling into Endpoint Manager, deprecating the existing Microsoft Store for Business service. This means it will no longer be possible to use the Microsoft Store to buy application licenses, though you will still be able to download free and individually licensed applications.
Part of the solution comes with changes to how Microsoft monetizes its store, along with big changes in how it fits into the Windows ecosystem. This allows vendors to provide their own licensing and payment frameworks outside of the Windows Store, and even to use their own download facilities. Where you used to have to buy and deploy tools like Adobe’s Creative Cloud directly from Adobe, you can now let users download the Creative Cloud application from the store and use assigned licenses to deliver applications to their PCs.
SEE: Ethics policy: Vendor relationships (TechRepublic Premium)
This way you can keep a separate contractual relationship with companies, assigning business subscriptions to users’ email addresses. The store is only an initial gateway – all downloads actually come from their own servers or hosted repositories.
Some businesses used the Store for Business to deploy features like the Windows HEVC codecs to their users. While pay-for applications like this won’t be available through the new Store services, users who are running an up-to-date Windows install won’t need to install many of these apps, as they are now features in current Windows releases.
Delivery via winget
One interesting aspect of the transition is the option of using winget with private repositories, either running your own or working with hosted services like Winget Pro. This approach avoids Microsoft’s restrictions on hosting paid applications. Once you have licensed installers, you can store them in a winget repository, using scripts to deploy the applications to users. You will need to provide your own auditing though, ensuring that you have the right number of licenses for deployed applications.
Those private winget repositories don’t need to be yours. It’s easy to see software vendors offering their own, and providing winget scripts for use in your networks. Here Endpoint Manager becomes the tooling for subscribing to these repositories, and for delivering download scripts to users based on their Azure Active Directory memberships.
Scripting winget is relatively simple. Microsoft provides examples of both batch scripts and PowerShell, so you can provide start-up actions that keep user applications up to date. Alternatively, remote PowerShell actions can handle updates and installs, using silent installs to minimize user disruption. How winget installs applications depends on the installer type, so you may need to repackage an installer to get the options you need.
It’s important to test winget scripts before you run them. It will run installs in sequence, launching one when the previous finishes; however, some installers launch secondary processes, having a master installer that runs other installers to add modules. This can cause winget to launch the next installer before one has finished. Use winget’s logs to understand how installs run and, if necessary, you can add timeouts between installs to avoid any possible clashes.
The road to modern management tools
By using Endpoint Manager to control access to public and private repositories, you’re moving into using modern management tools. Azure Active Directory becomes the source of knowledge about users, providing role-based access to repositories and to the scripts used to deliver applications. You can now be sure who has installed an application, who is up to date and who is actually using it. This approach simplifies keeping your network secure and understanding if you’re correctly licensed. With over-licensing as much of a problem as under-licensing, there’s the prospect of significant savings with the transition to a more managed software distribution model.
Intune users can then find published applications through the Company Portal, allowing them to install on their own. Admins can treat it as a more user-friendly version of the Configuration Manager Software Center.
If you’re using the Microsoft Store for Business, it’s time to start planning your transition to this new winget-powered world. Microsoft will first launch its own repository, which will be a mirror of the Microsoft Store, giving you access to all the apps available to Windows users. Private repositories will follow in 2023, giving you time to consider if you need to repackage applications.
How changes to the Microsoft Store mean changes to Autopilot
The changes will affect how you use Autopilot to configure new hardware remotely. As it’s currently built around using the Microsoft Store for Business to host deployment profiles, you’ll need to change to one of two options: Intune or the Microsoft 365 Admin Center. Autopilot profiles can be registered and managed using both tools, though you may have to manually migrate them from the Microsoft Store. If you’re working with an OEM to register new devices with Autopilot, you will need to give them a link to the new location for the necessary consent form, which will be available in the Microsoft 365 Admin Center.
The new Endpoint Manager/Microsoft Store integration is currently in private preview, with a wider public preview due soon. This will be available within existing Endpoint Manager instances, marked as preview, allowing you to start experimenting. Microsoft is making a big change here that affects how you both deploy new devices and manage applications, so you should start work on migrating to the new service as soon as possible to avoid any lapses in service that could affect delivering security updates to your users.
It’s clear from reading comments to Microsoft’s blog posts on the subject that the biggest issue for many admins is moving to Intune as their main management platform. Today’s Intune is now a mature management platform that offers a lighter weight approach to management using MDM tooling rather than group policies, an approach that’s more user friendly and reduces log on times. It may take some time to migrate policies to a new platform, moving groups of users across once you’ve configured and tested relevant policies.
Putting all the pieces together won’t be as hard as it looks at first. The tools may be different, but the underlying philosophy hasn’t changed. If anything, the addition of private repositories and winget support should mean a much more flexible platform for managing the software deployed to your fleet of PCs.