Windows
Silent installation of the MSI and EXE, deployment through winget and adding the package source
There are two Windows installers. The MSI installs into C:\Program Files for all users of the device and is the right choice for central deployment. The EXE installs into the user profile without admin rights and is meant for self-service installation.
Silent installation
# MSI, for all users of the device
msiexec /i DeutschlandGPT_1.4.0_x64_en-US.msi /qn
# EXE, for the signed-in user only
DeutschlandGPT_1.4.0_x64-setup.exe /S
Uninstall with msiexec /x <ProductCode> /qn, or through the uninstaller in the installation directory.
The ProductCode of the current version is served by the winget package source, see below. In Intune, upload the MSI as a Win32 app or a line-of-business app and pull the newest file through the stable URL from the overview.
Installing through winget
DeutschlandGPT is deliberately not in the public winget community repository, because we keep distribution under our own control. Instead we publish a manifest that always points at the latest MSI, including its checksum and ProductCode:
https://www.deutschlandgpt.de/api/desktop/winget/manifest.yaml
The file is served as DeutschlandGPT.Desktop.yaml and the package identifier is DeutschlandGPT.Desktop. The manifest installs the MSI with Scope: machine, so for all users of the device and with admin rights.
Local manifests have to be allowed on the device once. From an elevated prompt:
winget settings --enable LocalManifestFiles
Across a fleet, set the App Installer policy "Enable App Installer Local Manifest Files" instead (HKLM\SOFTWARE\Policies\Microsoft\Windows\AppInstaller, value EnableLocalManifestFiles = 1).
Then install with:
$manifest = "$env:TEMP\DeutschlandGPT.Desktop.yaml"
Invoke-WebRequest -Uri 'https://www.deutschlandgpt.de/api/desktop/winget/manifest.yaml' -OutFile $manifest
winget install --manifest $manifest --silent
winget upgrade will not find this package. An application installed from a local manifest has no
package source attached, so winget cannot update it on its own. To update, download the manifest
again and run the same command: that is what it is built for, UpgradeBehavior: install replaces
the existing installation. The simplest approach is to register the script above as a scheduled
task or a recurring Intune script. If you would rather use winget upgrade, add our package
source instead, see the next section.
While no version is published the endpoint answers with 503 rather than a half-filled manifest. A script should catch that case and skip the run.
Because winget installs the MSI here, everything on Controlling updates applies: the app will no longer update itself, keeping versions current is up to you.
Package source for winget upgrade
If you want to ship updates through your usual winget upgrade run, add our package source. It is of type Microsoft.Rest and always serves the latest version:
winget source add --name deutschlandgpt --type Microsoft.Rest `
--arg https://www.deutschlandgpt.de/api/desktop/winget
That is a one-time step per device and needs admin rights. Local manifests do not have to be allowed for this, so the setting from the previous section is not needed.
After that everything works like with any other source:
winget install DeutschlandGPT.Desktop --source deutschlandgpt --silent
winget upgrade DeutschlandGPT.Desktop --silent
The useful part: winget correlates by ProductCode, so it also recognises an installation you
rolled out through Intune that never went through winget. You do not have to reinstall anything.
Once the source is added, DeutschlandGPT shows up in winget upgrade as soon as a newer version
is available.
Across a fleet, deploy the source through the App Installer policy "Enable Windows Package Manager Additional Sources". Under HKLM\SOFTWARE\Policies\Microsoft\Windows\AppInstaller set the value EnableAdditionalSources (REG_DWORD) to 1 and add the source description to the AdditionalSources subkey:
$key = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\AppInstaller'
$source = @{
Name = 'deutschlandgpt'
Arg = 'https://www.deutschlandgpt.de/api/desktop/winget'
Type = 'Microsoft.Rest'
Data = ''
Identifier = 'deutschlandgpt-desktop'
} | ConvertTo-Json -Compress
New-Item -Path "$key\AdditionalSources" -Force | Out-Null
New-ItemProperty -Path $key -Name 'EnableAdditionalSources' `
-PropertyType DWord -Value 1 -Force | Out-Null
New-ItemProperty -Path "$key\AdditionalSources" -Name '1' `
-PropertyType String -Value $source -Force | Out-Null
All five fields are required, Data stays empty for a REST source. A source deployed this way cannot be removed by the user. You can verify the entry with winget source export, which is also the value's documented origin.
Two limits are worth knowing. The source only ever serves the latest version, so pinning to an older one via --version is not possible and is rejected with 404. And it does not change the fact that the MSI has no self-update: winget triggers the update, not the app.
Blocked execution inside the user profile
If you run AppLocker, WDAC or a comparable policy that only allows programs to start from C:\Program Files and C:\Windows, the per-user variant of the app cannot run at all. Deploy the MSI exclusively in that case. Automatic updates switch themselves off there, so no installation can appear inside the user profile.