Creating a custom Winget Repo

by

Winget is an excellent tool, but in some organizations you may not want to use the community repo (although all apps are checked), or you may want to host your own internal apps, but deploy and update via Winget.

One option is to simply use a custom manifest which I have covered here

The more comprehensive solution though is to host your own repo and fortunately the Winget team have released a PowerShell script to do the hard work for you.

NOTE: You need PowerShell 7!

NOTE 2: The keyvault has purge protection enabled the name you picked can only be used again if you wait 90 days after deletion!

To make things even easier, I’ve scripted it for you so you can either follow the instructions below, or just run the script and answer the prompts. You can find the script here:

https://github.com/andrew-s-taylor/public/blob/main/Powershell%20Scripts/AZ/setup-winget-repo.ps1

Or on PS Gallery

Install-Script -Name setup-winget-repo

Manually Installing

Step one is to download the PowerShell source (WinGet.RestSource-Winget.PowerShell.Source.zip) from here:

https://github.com/microsoft/winget-cli-restsource/releases

Extract to a folder (pick an easy path to save time later)

After extracting you need to unlock all of the files with this command:

Get-ChildItem -Path FILEPATH-HERE -Recurse | Unblock-File

We now need to install the AZ module as everything here is going into Azure

if (Get-Module -ListAvailable -Name Az) {
    Write-Host "AZ Module Already Installed"
} 
else {
    try {
        Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force 
        Write-Host "Az"
    }
    catch [Exception] {
        $_.message 
    }
}

One installed, connect to Azure with your tenant and optionally subscription (if you have a multi-subscription model)

Connect-AzAccount -Tenant TENANTID
Set-AzContext -SubscriptionId SUBSCRIPTIONID

Next, import the module we downloaded and unlocked:

Import-Module -Name FILEPATH\WinGet.RestSource-Winget.PowerShell.Source\Microsoft.WinGet.Source.psd1

Now for the creation itself, you have a few variables available here for location, naming and type so to make things easier, we’ll set those first:

$resourcegroup = "YOUR_RG_GROUP"
$region = "selected region name (short name)
$wingetitemname = "Prefix for all items created, has to be unique"
$installtype = "Basic, Enhanced or Demo"

The Resource Group will be created if it doesn’t exist already. The name also has to be exclusive as it creates a webapp.

The region will pair and I noticed when selecting UKSouth that it then failed as there wasn’t any capacity in UKWest, something worth considering.

Now run the command to create:

new-wingetsource -Name $wingetitemname -ResourceGroup $resourcegroup -Region $region -ImplementationPerformance $installtype -ShowConnectionInstructions

I had some issues here where the webapp failed so manually ran that step.

First, set the rest source path which is in the downloaded folder

$Restsourcepath = "FILELOCATION\WinGet.RestSource-Winget.PowerShell.Source\WinGet.RestSource-Winget.PowerShell.Source\Library\RestAPI\WinGet.RestSource.Functions.zip"

$webapp = Publish-AzWebApp -ArchivePath $RestSourcePath -ResourceGroupName $resourcegroup -Name $wingetitemname -Force

We then want to grab the URL and output with “/api” at the end which is what you need for Winget

$webappurl = (get-azwebapp -Name $wingetitemname).HostNames[0]

write-host "Your Winget Repo is available at https://$webappurl/api"

Finally add it in Winget:

winget source add -n "My Repo" -t "Microsoft.Rest" -a "URL HERE"

You can of course find out more at the official GitHub repo here:

https://github.com/microsoft/winget-cli-restsource

11 thoughts on “Creating a custom Winget Repo”

  2. I have long advocated for being able to add our existing Intune application repository as a custom winget source. Our apps are all already uploaded to Intune and it seems redundant to have to create another separate repository when Intune already has all of our apps!

    Is there a way to configure our Intune app repository as a valid winget source?

    Reply

    • I don’t think there will be any way to do that as the Intune apps are wrapped into an encrypted Intunewin format and the blob storage location is buried in Graph so creating the XML would be complex

      Reply

      • @Andrew, thank you for the reply!

        We have raised this with Microsoft repeatedly, as it feels like they could easily update winget to support Intune as a valid application repository – they own both components and should be able to wire in full support for the native Intune package format and source location.

        Reply

  3. When to create the latest steps to create the webapp we get some errors but cannot find why

    PS C:\temp> $Restsourcepath = “C:\Repo\WinGet.RestSource-Winget.PowerShell.Source\WinGet.RestSource-Winget.PowerShell.Source\Library\RestAPI\WinGet.RestSource.Functions.zip”
    PS C:\temp> $webapp = Publish-AzWebApp -ArchivePath $RestSourcePath -ResourceGroupName $resourcegroup -Name $wingetitemname -Force
    Publish-AzWebApp: Operation returned an invalid status code ‘NotFound’
    PS C:\temp> Publish-AzWebApp -ArchivePath “C:\Repo\WinGet.RestSource-Winget.PowerShell.Source\WinGet.RestSource-Winget.PowerShell.Source\Library\RestAPI\WinGet.RestSource.Functions.zip” -ResourceGroupName “2024wingetresource” -Name “2024wingetresource” -Force
    Publish-AzWebApp: Operation returned an invalid status code ‘NotFound’

    Reply

  4. very cool as a lot of the stuff you do is 🙂

    we are trying to install winget in autopilot ESP phase of our build to push a few default utils we need. Unfortuanately we get an error that winget cannot be installed as system. Any ideas how to get around this?

    Reply

  5. I didn’t realize it was this simple to get our own WinGet repo set up, thanks for highlighting this!

    Might be worth noting that the Azure Key Vault gets created with Purge Protection enabled, which cannot be disabled. I had problems with the web app part (even after manually running the Publish-AzWebApp command), and figured I’d just clear out the Resource Group and try again. Because the Key Vault has Purge Protection enabled, and because Key Vaults have to be globally unique, I’m now stuck waiting 90 days for the Key Vault to be fully purged from its current “soft-deleted” state before I can try to re-create the repo with the same desired name as last time.

    Reply

Leave a Comment