New FMA: Microsoft Access Database Engine 2016 Redistributable

[kitzy]

Goal

Add Microsoft Access Database Engine 2016 Redistributable as a Windows Fleet-maintained app.

Context

Found in the customer's ManageEngine ServiceDesk Plus Windows software-deployment catalog. Fleet has no FMA for it today.

• Vendor: Microsoft
• Source: winget Microsoft.AccessDatabaseEngine2016

Notes

The customer deploys both x86 and x64. They register separate ARP entries, so this likely needs two FMAs — same split as vc-redist-x64.

Acceptance criteria

• Input added under ee/maintained-apps/inputs/winget/
• Identity fields verified against the real installer — unique_identifier equals the registry DisplayName, and the publisher in the exists query equals the registry Publisher
• Passes the FMA validator: install → detect → uninstall
• Icon exists or is generated

[kitzy]

Duplicate check run against origin/main (1,382 catalog entries in ee/maintained-apps/outputs/apps.json) — no existing FMA for this app on either platform.

No near matches of any kind in the catalog.

Naming: if this ships as separate x86 and x64 FMAs, put the architecture in the catalog name, following the existing Microsoft Visual C++ 2015-2022 Redistributable (x64) entry. Two entries sharing one name would collapse into a single library entry and could not be told apart.

[kitzy]

Research findings — this one needs a decision before implementation

1. The registry DisplayName is nothing like the winget name

winget's locale manifest says PackageName: Microsoft Access Database Engine 2016 Redistributable. The actual ProductName in the MSI is:

ProductName    Microsoft Access database engine 2016 (English)
Manufacturer   Microsoft Corporation
ProductCode    {90160000-00D1-0409-1000-0000000FF1CE}
UpgradeCode    {00160000-00D1-0000-1000-0000000FF1CE}
ALLUSERS       1

Two traps in one string:

• Casing. It is "database engine", not "Database Engine". osquery's = on TEXT is case-sensitive, so the winget-derived name would never match.
• A locale suffix. The name ends in (English), and the ProductCode embeds the LCID (0409). Other language builds register different names and different ProductCodes.

Whichever way this ships, unique_identifier must be Microsoft Access database engine 2016 (English) verbatim.

2. The .exe is a self-extracting wrapper, and winget calls it portable

The download is not an installer — it extracts to a folder containing AceRedist.msi, InstallUCRT.exe, three KB2999226 .msu packages, and this setup.cmd:

InstallUCRT.exe
...
msiexec %1 /i AceRedist.msi

So the outer exe forwards its first argument straight to msiexec, which is why /quiet works.

The problem is that winget types this as InstallerType: portable. That is a delivery classification, not a real installer format, and the ingester does not recognise it:

• portable is not in vendorTypes, so the ingester never falls back to deriving the type from the .exe URL.
• portable is not in fileTypes either.
• Matching it as-is would require "installer_type": "portable" with "installer_scope": "" — no existing FMA does this, so it is unproven.

The principled fix is one line: add portable to vendorTypes so the type is derived from the URL extension (exe), exactly as wix/nullsoft/inno already do. That is a shared-tooling change, though, so I am not making it unilaterally.

3. Real deployment hazard: Office bitness conflict

Access Database Engine refuses to install when Office of the opposite bitness is present, and the customer deploys both x86 and x64 (so this is likely two FMAs, per the earlier naming note). This will install fine on a bare CI runner and then fail on real hosts that have Office — meaning a green validator here would not mean much.

Options

1. Add portable to vendorTypes in the ingester (one line + test), then ship this normally as an exe.
2. Try "installer_type": "portable" with an empty scope and see whether it survives ingest and validation — no code change, but a first-of-its-kind input.
3. Drop it as a poor FMA candidate, given the Office-bitness conflict makes it unreliable on exactly the hosts that want it.

Holding here rather than guessing.

[kitzy]

Built in #50365 (draft). Two corrections to my earlier notes on this issue:

1. No ingester change is needed. I expected portable to require adding it to vendorTypes, but I tested it first: "installer_type": "portable" with an empty scope matches cleanly, and the generated output carries no installer type (Fleet infers .exe from the URL). It works with no shared-code change.

2. Putting the architecture in the catalog name would not have helped. I suggested that earlier, following the Microsoft Visual C++ 2015-2022 Redistributable (x64) precedent. It is wrong here: x86 and x64 register the identical registry DisplayName (Microsoft Access database engine 2016 (English)), differing only by product and upgrade code. Distinct catalog names would still produce identical exists queries, so the two would detect each other. Shipping x64 only instead.

The Office bitness conflict is handled with a pre-flight check in the install script that exits with an actionable message, following @allenhouchins' guidance from #50323. Note the CI runner has no Office, so a green validator does not exercise that path.