Provisioned winget, winget.exe available only after some time

[GethDeeo]

I've provisioned winget (along with it's dependency package) into a fresh expanded Windows 10 image. After first boot, I've wanted to use it right away, but winget.exe is not available.
After a couple of (let's say ~15) minutes later, winget.exe is available and working.
If I restart right after first boot, it's available immediately, but I want to avoid restart if it's possible.

I'd like to use winget as a part of a script configured to run as FirstLogonCommands/SynchronousCommand. Now I'm a total noob to provisioning apps, so I've got 2 questions:

1. Is that timespan normal or am I doing something wrong? Can the process be sped up?
2. On what condition should the script wait? In my test run I just polled Get-Command, but it seems pretty clunky to me.

[jedieaston]

I think the reason it isn’t accessible after first boot is that Windows 10 doesn’t include winget, but it can pull it via a Microsoft Store update. Eventually it reaches out in the background to do the update without opening the store, and winget appears along with the other new apps. There’s no real way to know when this happens, although you could use Get-AppxPackage to see when the version of Microsoft.DesktopAppInstaller changes to one that includes winget.

To resolve your problem, you can install it silently via a script that uses the packages posted here on GitHub, allowing instant use. I wrote one here, but it’s really just using Add-AppxPackage and downloading winget and the dependency libraries (latest version of the VCLibs for your platform).

After running that script, you will have winget available for use immediately, and any further updates will come through the Microsoft Store.

[GethDeeo]

I thought that by using Add-AppxProvisionedPackage on the expanded image that never booted (instead of Add-AppxPackage once booted) will have the added benefit that every user created onwards (including the first one) will have winget already available.
And to an extent it's working fine, except that magical ~15 minutes delay (it's there whether the system has internet connection upon first boot or not).
I can try and rearrange my scripts, but I'm still very curious about that delay in case of provisioning.
My idea is that this scenario is supported, because *_License1.xml is posted with the releases, and that's only needed while provisioning.

[GethDeeo]

Ok, I've worked around the issue.
At first boot, I re-register Desktop Installer from the the provisioned appx install location with this snippet:
(Get-AppxProvisionedPackage -Online -LogLevel Warnings | Where-Object -Property DisplayName -EQ Microsoft.DesktopAppInstaller).InstallLocation -replace '%SYSTEMDRIVE%', $env:SystemDrive | Add-AppxPackage -Register -DisableDevelopmentMode

The InstallLocation property erroneously contains the string %SYSTEMDRIVE% unexpanded. Updating apps via Store corrects it, but the whole idea was not to depend on Store :)
After the command completes, winget is there and working.

[NickSlash]

Got my hopes up, I thought that the %SYSTEMROOT% bit was the reason the package wouldn't install for new users.

Loading HLKM\SOFTWARE from a mounted wim image and reading the InstallLocation for pretty much all packages shows %SYSTEMROOT% so its likely not an error, just inconvenient for Powershell.

I've been using a similar command to register the package on new users:

Add-AppxPackage -RegisterByFamilyName -MainPackage (Get-AppxProvisionedPackage -Online | Where-Object { $_.DisplayName -eq "Microsoft.DesktopAppInstaller" }).PackageName