MSI 1919 and 27502: ODBC, COM+ and SQL Setup Actions Fail Late in Install

Fix it now

These appear once setup stops installing and starts configuring. Microsoft publishes 1919 as an error configuring an ODBC data source, with the ODBC error the driver returned inside the message. 27502 is not a Microsoft code at all: it comes from the package you are running, and the text beside it is the real diagnosis.

%windir%\System32\odbcad32.exe
%windir%\SysWOW64\odbcad32.exe
sqlcmd -S SERVER\INSTANCE -E -Q "select @@version"

1. Read the message properly. For 1919 it names the data source, the driver and an ODBC error number returned by the driver – that inner number is what to work from.
2. Open the ODBC administrator matching the application’s bitness and check the Drivers tab for the driver the package expects. System32 manages 64-bit drivers and SysWOW64 manages 32-bit ones, which is the opposite of what the folder names suggest.
3. Install the missing driver in the right architecture, and create any data source the package needs on the System DSN tab rather than the User DSN tab.
4. For a connection failure, test it by hand with sqlcmd from the same machine before you rerun setup.

A User DSN belongs to the profile that created it. A per-machine install runs as SYSTEM and cannot see it, which is why a data source you can test successfully is still invisible to setup.

If a manual connection succeeds and the driver is listed, rerun the installer and it usually completes. If not, the next section covers the identity these steps run under.

Why it happens

An installer that needs a database or a component service does two very different jobs. First it copies files, which needs nothing but disk access. Then it runs actions that reach outward: creating an ODBC data source, registering a COM+ application, connecting to SQL Server to create a database and its objects. Those steps depend on things the package does not control, which is why they fail on machines where the file copy went perfectly.

The account matters more here than anywhere else in a setup. Per-machine custom actions run as SYSTEM, which on the network presents as the computer account. A connection string that works when you test it interactively can fail during setup because the credentials being offered are not yours. Data source scope has the same trap: a User DSN belongs to your profile and is invisible to SYSTEM.

1928 and 1929 are the COM+ equivalents – published as the installation failing to install, and failing to remove, a COM+ application. They generally mean the COM+ infrastructure or the transaction coordinator is unhealthy rather than that the package is wrong.

27502 is worth being clear about, because it is routinely written up as though Microsoft published a meaning for it. It is not in Microsoft’s Windows Installer error message list and no Microsoft documentation page defines it. It is raised by the setup package you are running, and the message beside it – usually naming a server, an instance and a provider – carries everything useful.

Full reference

What is published, and what is not

The ODBC error number inside a 1919 message is the value to work from and the one most people skip. It comes from the driver, not from Windows Installer, so it is documented by whoever wrote the driver. It distinguishes a driver that is absent from one that is present and refusing the connection, and those need entirely different work.

Where each symptom usually leads

Testing the connection the way setup will

Testing as yourself proves very little, because setup will not be you. Where the failure only happens under a deployment tool, reproduce the identity rather than the command: run the test from a scheduled task configured to run as SYSTEM, or from your management tool’s own script step, and compare. Nine times out of ten the difference is that the computer account has no login on the instance.

sqlcmd -S SERVER\INSTANCE -E -Q "select @@version"
sqlcmd -S SERVER\INSTANCE -U <login> -P <password> -Q "select @@version"

Data source scope, in one paragraph

A User DSN is stored in the profile of the account that created it and is visible only to that account. A System DSN is stored machine-wide and is visible to every account, including SYSTEM and service accounts. Anything a service, a scheduled task or a per-machine installer will consume must be a System DSN. This is the single most common reason a data source that tests perfectly is reported as missing by setup.

When the configuration step still fails

1. Ask whether the step can be skipped and performed afterwards. Many packages allow the database to be created separately by a script the vendor supplies.
2. Check whether the installer has its own log, separate from the MSI log. Products that talk to SQL Server usually write one, and it names the actual connection error.
3. Confirm the instance is not in a state that refuses new connections – single-user mode, or a failed-over availability group replica.
4. Check the driver architecture once more against the application, not against the operating system.
5. If the product is a third-party application, send its own log to its vendor. The Windows Installer log will not contain the answer.

Every code this article covers

Confirm the fix worked

1. Open the matching ODBC administrator and confirm the data source is on the System DSN tab, then use its Test button.
2. Run sqlcmd -S SERVER\INSTANCE -E -Q "select @@version" and confirm it returns a result.
3. Rerun the installer and confirm the configuration stage completes without an error dialog.
4. Start the application and confirm it connects to its database on first launch.
5. If the install is deployed, run it once through the deployment tool and confirm the tool records success.

Questions people ask about this