Files
fleet/ee/maintained-apps/inputs/winget/microsoft-access-database-engine-2016.json
kitzyandAllen Houchins 332d8a2cee Add Microsoft Access Database Engine 2016 Redistributable as a Windows Fleet-maintained app (#50365)
**Related issue:** Resolves #50325

Adds Microsoft Access Database Engine 2016 Redistributable as a Windows
Fleet-maintained app, from winget `Microsoft.AccessDatabaseEngine2016`
(16.0.5044.1000, x64). Found in a customer's Windows deployment catalog
with no Fleet equivalent.

## No ingester change was needed after all

When I scoped this I expected to need a one-line change, because winget
types the installer as `portable`, which is not in the ingester's
`vendorTypes` or `fileTypes`. I tested it first: `"installer_type":
"portable"` with an empty scope matches cleanly, and since the generated
output carries no installer type (Fleet infers `.exe` from the URL), the
result is correct as-is.

This is the first FMA input to use `portable`. If reviewers would rather
not establish that precedent, adding `portable` alongside
`wix`/`nullsoft`/`inno` in `vendorTypes` would let the type fall through
to the URL extension and the input could then say `exe`. Both work. I
chose the one that touches no shared code.

## Identity: winget's name is wrong twice over

winget's locale manifest says `Microsoft Access Database Engine 2016
Redistributable`. The MSI says:

```
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: the real name is lowercase `database engine`, and it carries
an `(English)` locale suffix with the LCID (`0409`) embedded in the
ProductCode. osquery's `=` on TEXT is case-sensitive, so the
winget-derived name would have matched nothing.

## x64 only, deliberately

The customer deploys both architectures, but **x86 and x64 register the
identical DisplayName**. I confirmed this by extracting both installers:

| Arch | ProductName | UpgradeCode |
|---|---|---|
| x64 | `Microsoft Access database engine 2016 (English)` |
`{00160000-00D1-0000-1000-0000000FF1CE}` |
| x86 | `Microsoft Access database engine 2016 (English)` |
`{00160000-00D1-0000-0000-0000000FF1CE}` |

They differ only by product and upgrade code. Two FMAs could not be told
apart by an exists query, so installing one would make the other report
itself installed. Shipping x64 only avoids that. This also corrects my
earlier note on the issue suggesting the architecture go in the catalog
name; that would distinguish the catalog entries but not the detection
queries, so it would not have helped.

The uninstall script resolves the product from the x64 upgrade code
rather than a product code, so it removes the x64 build and leaves an
x86 install alone.

## The Office conflict is handled, not hidden

This redistributable refuses to install when Office of the opposite
bitness is present. Following the same approach @allenhouchins set out
for HandBrake in #50323, the install script checks the Click-to-Run
platform first and exits with an actionable message instead of a bare
installer failure:

```
32-bit Microsoft Office is installed on this host (Click-to-Run platform: x86).
The 64-bit Access Database Engine cannot be installed alongside it. Use the 32-bit redistributable instead.
```

**A green validator here proves less than usual.** The CI runner has no
Office installed, so it exercises the happy path only. The conflict this
app is known for cannot be reproduced there. That is a limitation of the
environment, not evidence the app is safe on managed hosts, and it is
the main thing worth weighing before merging.

## Other notes

- Installer SHA confirmed against a local download of
`accessdatabaseengine_X64.exe` (`04e96c9f…03de`).
- The download is a self-extracting package. Its `setup.cmd` runs
`InstallUCRT.exe` and then `msiexec %1 /i AceRedist.msi`, which is why
`/quiet` reaches the MSI.
- **No icon.** The MSI has no `ARPPRODUCTICON` and no Icon table, so
there is nothing to extract. The app falls back to the generic software
icon, which suits a redistributable with no user-facing app.

# Checklist for submitter

- [x] QA'd all new/changed functionality manually


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added Microsoft Access Database Engine 2016 Redistributable as a
supported Windows application.
* Added silent installation and uninstallation workflows with
architecture checks, registration detection, timeout handling, and
standard success-code support.
* Included package metadata, version information, download verification,
Developer tools categorization, and reliable installation-state
detection.
* Added handling for existing installations and validated installer
outcomes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Allen Houchins <allenhouchins@mac.com>
2026-08-02 22:59:48 -05:00

13 lines
636 B
JSON

{
"name": "Microsoft Access Database Engine 2016 Redistributable",
"slug": "microsoft-access-database-engine-2016/windows",
"package_identifier": "Microsoft.AccessDatabaseEngine2016",
"unique_identifier": "Microsoft Access database engine 2016 (English)",
"install_script_path": "ee/maintained-apps/inputs/winget/scripts/microsoft_access_database_engine_2016_install.ps1",
"uninstall_script_path": "ee/maintained-apps/inputs/winget/scripts/microsoft_access_database_engine_2016_uninstall.ps1",
"installer_arch": "x64",
"installer_type": "portable",
"installer_scope": "",
"default_categories": ["Developer tools"]
}