Any Update on it? When are we planning to fix it?

The bug is open for someone to work on. If you're volunteering, see WiX Toolset Development.

Hi Bob Arnson,

I want to work for this fix.

Thanks,
Chandra Patibandla.

Please create a WIP to describe how you want to make the change.

We found same issue very important when installing against Windows 2016 Server, for instance.
This means to tweak the server and restart SQL Service in order to use our installer...

Did you start working on that fix Chandra ?
S.

Do we have a link to WIP created for this issue?

No WIP has been created. No one seems to be working on this issue at this time.

I want to work on it.
I did not get any option to create new WIP, so here is the overview of how I am planning to fix it.

FIX Details:
SQLOLEDB does not have TLS1.2 support, so need to use SQL native Client for it.

In the SqlConnectDatabase() API in file ..\wix3\src\libs\dutil\sqlutil.cpp

CoCreateInstance is being called with CLSID_SQLOLEDB as the first argument.
hr = ::CoCreateInstance(CLSID_SQLOLEDB, NULL, CLSCTX_INPROC_SERVER,
IID_IDBInitialize, (LPVOID*)&pidbInitialize);

Fix would be to call it with SQLNCLI_CLSID and if that fails, then as a fallback call with CLSID_SQLOLEDB.

OLD CODE:

//obtain access to the SQLOLEDB provider
hr = ::CoCreateInstance(CLSID_SQLOLEDB, NULL, CLSCTX_INPROC_SERVER,
	IID_IDBInitialize, (LPVOID*)&pidbInitialize);
ExitOnFailure(hr, "failed to create IID_IDBInitialize object");

NEW CODE:

//obtain access to the SQLOLEDB provider  
hr = ::CoCreateInstance(SQLNCLI_CLSID, NULL, CLSCTX_INPROC_SERVER,
	IID_IDBInitialize, (LPVOID*)&pidbInitialize);	
if (FAILED(hr))	
{		
          hr = ::CoCreateInstance(CLSID_SQLOLEDB, NULL, CLSCTX_INPROC_SERVER,
		           IID_IDBInitialize, (LPVOID*)&pidbInitialize);	
}
ExitOnFailure(hr, "failed to create IID_IDBInitialize object");

Other related changes:

1. SQLNCLI.h file has to be copied to ...\wix3\src\libs\dutil\inc folder
2. SQLNCLI.h has to be included in the ....\wix3\src\libs\dutil\dutil.vcxproj
3. SQLNCLI.h has to be included in the ....\wix3\src\ext\ca\serverca\scasched\precomp.h
4. SQLNCLI.h has to be included in the ....\wix3\src\libs\dutil\inc\sqlutil.h
5. #define SQLNCLI_OLEDB_IGNORE_DEPRECATION_WARNING needs to be defined in file ..\wix3\src\libs\dutil\sqlutil.cpp

http://wixtoolset.org/development/wips/0000-wix-improvement-proposal/ describes how to create a WIP.

WiX Improvement Proposal mentions that "..... Not every change to the WiX toolset must have a WIP. Bug fixes, for example, are often sufficiently defined in the issue tracker....."
The change i am proposing is very minimal (only a 2-3 lines of change), does it require to go via WIP process?

You can start a thread on the wix-devs mailing list to start. Adding sqlncli.h needs to be discussed.

Started thread on wix-devs mailing list yesterday.

Hi barnson, I posted the solution last week, did you get the chance to look in it?

This is fixed in WiX v3.14.0.1703

@robmen Where can I get WiX 3.14? The Releases page stops at 3.11.

@eqr look in the "Weekly Releases".

@robmen Thank you.

@ArthurWelch when WiX v4.0 is marked stable (sometime later this year).

@robmen Is there a ballpark (summer/fall/winter) on the ETA? We would ideally like to wait for the weekly build to become a stable release.

A lot of our customers are credit unions and they need to be complaint for PCI Data Security Standard (PCI DSS) for safeguarding payment data they are required to update to newer TLS.

@robmen Thanks for the update

@robmen Any latest development on releasing a stable build for Wix 3.14 or Wix 4.0. We would really like to consume this fix as most of our installation environment is shifting to TLS 1.2

Hi,
Where are the weekly releases of 3.14 for download?
Would it be possible to get this fix pushed up to a stable v3 release since we use nuget?
Windows machines by default require a secure version of tls now, and this is breaking us ...

WiX v3.14 is intended to be released with the rollout of WiX v4. Until then, the latest builds can be found by following the link for development builds from this page.

WiX v4 is intended to be obtained from NuGet. WiX v3 isn't (although 3rd parties have packaged builds and placed them on NuGet, even giving credit to @robmen).

We have an environment where TLS 1.1 and 1.0 are both disabled on the SQL server. We are using the SqlDatabase and SqlString components to deploy database changes during install which are failing in this environment. If we enable TLS 1.0 and 1.1 then the installation succeeds.

@robmen mentions that this issue is fixed in 3.14.0.1703 and @barnson mentioned that this issue is a duplicate of #5794. So I'm not sure what to try next.

We have built the installer using WiX v3.14.0.1703 as well as v3.14.0.2812 with similar results.

Error:
MSI (s) (64:1C) [13:18:20:146]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIFDF0.tmp, Entrypoint: CreateDatabase
CreateDatabase: Error 0x80040154: failed to create to database: 'TmpDatabase', error: unknown error
Error 26201. Error -2147221164: failed to create SQL database: TmpDatabase, error detail: unknown error.
MSI (s) (64!DC) [13:18:39:273]: Product: TestProduct 15.2.0.11 -- Error 26201. Error -2147221164: failed to create SQL database: TmpDatabase, error detail: unknown error.

CustomAction CreateDatabase returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

I believe that v3.14.0.2927 would be the first build that would contain all parts of that fix. The newest v3.14 is v3.11.2.4516.

@BMurri thanks for the response. Unfortunately, it wasn't because we weren't using the right build. It wasn't obvious here, but for this to work the target machine must have the SQL Native Client (2012) installed. The change made to WiX was to prioritize the connection using the SQL Native Client which supports TLS 1.2. If that connection attempt fails it falls back to SQL OLEDB which until recently doesn't support TLS 1.2.

For us, it was a perfect storm of mismatched dependencies and prerequisites that caused the issues. Now we have a working configuration. As long as the target system has the SQL Native Client (2012) installed then TLS 1.0 and 1.1 can be disabled. Hope this will help someone else out there running into the same issues.

Thanks!

I'm glad it's working and thank you for closing the loop with useful information for whomever runs across this next

@firegiantco Need this one in v4, too.