I recently got a new laptop and had to go through the ritual of reinstalling all my programs and drivers. I sometimes work with SSIS locally to import data from Excel and occasionally do demos with Power BI where I read from an Access database so I needed to install the ACE OLE DB provider. If you try to do either of those things without the ACE OLE DB provider you will get a message like the one below.
The ‘Microsoft.ACE.OLEDB.12.0’ provider is not registered on the local machine.
I needed both the 32-bit and the 64-bit adapters to cover my various use cases. I started by installing the 64-bit Microsoft Access Database Engine 2010 Redistributable. If you have ever attempted this, you know there is a secret. You cannot install the 2010 Access database engine with a different processing architecture (bittedness) from your Office install (or install both versions of the 2010 Access database engine) without a workaround. If you try, you will get an error message.
There are two options for getting the other version installed.
Option A: Install the 2007 Office System Driver: Data Connectivity Components
The 2007 Access database engine can read the same format, but didn’t have a 64-bit install. It doesn’t have the check to see what other products are on your machine and can co-exist peacefully with the 64-bit 2010 Access engine.
Option B: Install from the Command Line and Use the Passive Switch
- Open the command prompt.
- Type the file path and file name for your Access Database Engine install file.
- Follow it with a space and then “/passive” and then hit Enter.
- Delete or rename the mso.dll registry value in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths
Note: A helpful commenter has informed me that for Access 2016 the switch is /quiet rather than /passive.
I wrote up a document for this a while back for a client, but I can never remember where I put it. So I’m posting this on my blog to make this info easier to find for me as well as you.
Data Savvy 
Meagan, the repeated installation attempts did not lead to the creation of Microsoft.ACE.OLEDB.16.0 entry under Server Objects->Linked Servers->Providers in SSMS on the client, nor in the registry of the client under HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Microsoft SQL Server -> MSSQL11.MSSQLSERVER -> Providers (described in your post above). I left a reply here yesterday close to 2 pm CT, it has not been published. Will you have any idea how this can be resolved?
Hi, Art. I’m sorry I don’t have other ideas how to resolve your issue.
Worked like a magic for SSIS.. able to install 32 bit and package running successfully
What solution fixed your problem? We had a recent install of office 365. From then I am getting this ACE.OLEDB.12.0 provider issue from table to Excel or from excel to Table data flow. Please advise as it’s very urgent
Hola, tengo el mismo problema, en un pc que tiene office 365 me arroja el error ACE.OLEDB.12.0 , pero en uno que tiene instalado Microsoft Office 2013 si funciona, y lo que pasa es que en el equipo que tengo office 365 no instalan el paquete office 2013 por politicas de la empresa y seguridad
It works, Thanks Meagan!!!
Four years later and still helped my cause. Thank you!
THANK YOU!!!
I’ve been hunting for this all morning after I got a newly imaged laptop from my company.
Installing it from the command line worked like a charm!
Thanx! This works! Couldn’t import data from xslx (over 200k records) to SQL Server, using MSSMS 18.2, said Microsoft OLEDB 16 not registered. This magic worked, I was able to import.
Thank you so much! It worked for me after having issues with running SSIS Excel Connection Manager. I wasn’t able to find the mso.dll location as indicated but it still seems to work for me!
i didn’t need to run the command line. but your post gave me the idea to try both 32 and 64 bit. i originally only had 64 bit installed and was still getting the error. thanks to your post, i installed the 32 bit as well and… finally!
thank you.
Thanks heaps for this.
THANK YOU THANK YOU THANK YOU!!!!!!!!!!!!!!!!!!!! I have been looking for a solution to this problem for over a day now!!!!!!!!!!!!!! I have 64-bit Office installed and am running Visual Studio 2019 with SSDT and the SSIS extension installed. VS and SSDT and the SSIS Extension I believe are all 32-bit applications and I could not read an Excel file. Your second option above works. (install from the command line with the /quiet option. /passive yielded the same error. /quite succeeded!!! THANK YOU. Mike
OMG !!! Been looking for this answer for years!! The silent install worked a treat for the 32bit library !
It worked for me too ! “/quiet” for 2016 version. Thank you. Although, I didn’t have to delete/rename the mso.dll
Is there any information why the mso.dll should be deleted/rename in the registry? In the mentioned office version “…\Microsoft\Office\14.0\…” no mso.dll entry is available in my registry. I only found the mso.dll entry in the “…\Office\15.0\…” and “…\Office\16.0\…” folders. Should the mso.dll removed from all versions? Or only from the installed version with quiet/silent option?
I got some update errors for microsoft x64 security updates, but after a restart it looks like the updates could be installed. I don’t know if this was a side effect of the installation with quiet/silent.
I’m not aware of the silent install having that side effect.
Brilliant. Thanks!
Downloaded both AccessDatabaseEngine.exe & the _x64 version. Only ran the first from the cmd line. No change to the registry, and it works now.
I had to use this last year when we were on Office 14 or so…. and here I am again doing my annual update of my hated SSIS package and have to refer to this again. THANK YOU, this is continually useful. I did both /passive and /quiet just to be safe. 🙂
For Office 16 (Office 365) there isn’t a key similar to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths in the 16.0 folder.
I did find the following, however:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Common\FilesPaths
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Common\FilesPaths
I also found some for older versions than 16.0
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\12.0\Common\FilesPaths
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\14.0\Common\FilesPaths
I’m leaving those alone for now to see how it turns out… but will start carefully pruning these entries (especially the 16.0 ones) if it seems necessary!