Deploy with Intune
Wrap the Wintty Pro Enterprise MSI with the Win32 Content Prep Tool, assign it in Intune, and detect installs from the HKLM registry values the MSI writes.
Wintty Pro Enterprise ships as a per-machine Windows Installer package, built for the tools that deploy software across a fleet. Getting it onto machines through Intune takes four decisions: how to wrap the MSI, what command installs it, what rule detects it, and what your upgrade rules compare. Each one is short, and none of them involve custom install logic, because the package has none.
Enterprise licensing is arranged directly rather than through a sponsorship page, because invoices, purchase orders and seat counts do not fit a GitHub checkout. What you receive is the Enterprise MSI: a single signed package, with the signature naming Ship Digital Ltd.
If you are still choosing between tiers, what each tier includes compares them row by row. To start the licensing conversation, reach out to @polyMatto on X, or by email, which is easy enough to find.
The install is per-machine and lands in Program Files\Wintty. The
whole footprint:
- the program files themselves,
- one Start menu shortcut, named Wintty, carrying the app identity so pinning and notifications attach to the right window,
- two registry values under
HKLM\Software\Wintty\Install.
Nothing goes on PATH, there is no desktop shortcut, and no service or driver is installed. Uninstall reverses everything above, registry values included.
The two registry values exist for the fleet tools reading them:
| Value | Contents |
|---|---|
InstallVariant | Always Enterprise for this package. |
InstallVersion | The release version as shipped, for example 1.0.0-rc.2. |
InstallVersion is the version the release was called, not the MSI's
numeric ProductVersion. The difference matters when you write upgrade
rules; the mapping is further down this
page.
Intune deploys an MSI two ways. A line-of-business app takes the MSI directly but fixes the install behaviour and detects by product code. The Win32 app route wraps the package with the Win32 Content Prep Tool and leaves the install command, the detection rule and the uninstall command to you. That is the route this page uses.
-
Put the MSI in a folder of its own.
-
Wrap it:
IntuneWinAppUtil.exe -c C:\packages\wintty -s Wintty.Pro.Enterprise.msi -o C:\packages\out -
In the Intune admin center, go to Apps > Windows > Add and choose Windows app (Win32). Upload the
.intunewinfile from the output folder.
On the Program tab of the app:
- Install command:
msiexec /i "Wintty.Pro.Enterprise.msi" /qn /norestart - Uninstall command:
msiexec /x "Wintty.Pro.Enterprise.msi" /qn /norestart - Install behavior: System
Use the file name your build arrived with. The package takes no
install-time properties, so /qn is all the silence it needs. Nothing
in the package schedules a restart; /norestart also holds off the
one Windows can ask for when an upgrade replaces files the app has
open. System is the right behaviour, and the required one: a
per-machine install from a user context would fail without elevation.
Give Intune a registry rule pointed at the value the package writes for exactly this purpose:
| Field | Value |
|---|---|
| Path | HKEY_LOCAL_MACHINE\Software\Wintty\Install |
| Value name | InstallVariant |
| Detection method | Value comparison |
| Operator | Equals |
| Value | Enterprise |
Leave the 32-bit registry check off. The package is 64-bit and writes
the real HKLM\Software; a rule reading the 32-bit view lands in
Wow6432Node, finds nothing, and reinstalls on every check.
The MSI carries a numeric ProductVersion because Windows Installer compares exactly three decimal fields when it decides whether an install is an upgrade, a repair or a downgrade. Wintty releases are SemVer and can carry a prerelease tag, so the build maps the release onto a numeric version before packaging:
| Released as | MSI ProductVersion |
|---|---|
1.0.0-rc.1 | 1.0.1 |
1.0.0-rc.2 | 1.0.2 |
1.0.0 | 1.0.99 |
The third field is the patch number times one hundred plus the prerelease number, and a final release reserves ninety-nine so it always sorts above the prereleases of the same patch. A fourth field would not have carried the prerelease either: Windows Installer ignores it when comparing.
When a supersedence or upgrade rule needs a version, compare the
ProductVersion the MSI carries. When a report wants to say which
release a machine runs, read InstallVersion from the registry, which
names the release the way it shipped.
Deploying a newer MSI replaces the older install in place: Windows Installer uninstalls the previous version and installs the new one, so no parallel copy appears in Add/Remove Programs. Re-deploying the same version is a repair, which is what you want when a machine drifted or the same build was pushed twice. Deploying an older version is refused, and the machine keeps the newer one:
A newer version of Wintty Pro Enterprise is already installed.
The uninstall command removes the program files, the Start menu
shortcut and HKLM\Software\Wintty with both values. Per-user
settings are outside the package, so uninstall does not clear them.
The same MSI deploys the same way in the other two tools: SCCM takes it as a Windows Installer deployment type on an application, and Group Policy assigns it under Computer Configuration, Software Installation. Once machines have it, six Group Policy policies cover the settings a fleet cares about: the update channel, with an off switch for machines that take their updates from you; a shell allowlist; a log path for audit collectors; and forcing the Windows default terminal handoff.