Microsoft Access Database Engine

Installing Access Database Engine 2016 x64 alongside Office x86

In Power BI, you can open XLSX files without any additional drivers, but opening XLSB files requires you to first install the Access Database Engine driver (available for free at https://www.microsoft.com/en-us/download/details.aspx?id=54920) or you’ll get an error like this:

We encountered an error while trying to connect. Details: "Excel Workbook: the 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. The 64-bit bersion of the Access Database Engine 2010 Access Database Engine OLEDB provider may be required to read. — ‘Microsoft.ACE.OLEDB.12.0’ provider error message

If you have Microsoft Office installed, you already have this component, but most people use a version of Office that’s x86 – since Power BI is x64, you’ll need the x64 version of the driver as well. However, if you try to install it with Office x86 on your computer, you’ll get this error and you’ll be stuch:

Microsoft Access database engine 2016 x64 Installation Error screenshot - "You cannot install the 64-bit version of Microsoft Access Database Engine 2016 because you current have 32-bit Office products installed. If you want to install 64-bit Microsoft Access Database Engine 2016, you will first need to remove the 32-bit installation of Office products. After uninstalling the following product(s), rerun setup in order to install 64-bit version of Micorsoft Access Database Engine 2016: Office 16 Click-to-Run Extensibility Component" — Microsoft Access database engine 2016 x64 Installation Error screenshot

There’s a way to install both! To avoid this error and install the x64 database engine without removing Office x86, you need to download the installation for the Access Database Engine x64 and run the installation with a command line switch:

AccessDatabaseEngine_X64.exe /quiet

Command to install Access database engine using the "/quiet" switch to run to installation without an error

Once you run this command, you’ll get a black command window for a few seconds, and then it will close once it’s done. To confirm that it’s installed successfully, you can either check for “Microsoft Access database engine 2016” in your Windows “Programs and Features” window, or you can just launch Power BI and attempt to import an XLSB file!

I haven’t noticed any ill effects to doing this, but if you do have issues, comment below.

Network not working after removing Symantec Endpoint Protection

About a year ago, I made the switch from Symantec Endpoint Protection 12 to Microsoft Forefront on a small network I manage, and the transition was mostly smooth. I noticed a few weeks ago, though, that one of my servers still had SEP installed, though it wasn’t running. I uninstalled SEP, thinking it would go smoothly, and on reboot, I lost connectivity to the server. No ping, no remote desktop – nothing.

On rolling over to the server and checking the desktop, the network connectivity was completely dead – I couldn’t ping the gateway or browse the internet at all. Using Device Manager to uninstall the network card and rebooting didn’t do any good, not did attempting to update drivers. However, in device manager, I could see a “Teefer2” entry for every one of my network connections, and it was set to disabled – this is the Symantec Network Threat Protection driver, and it monitors your network activity. Thinking this could be the problem, I attempted to right-click -> Uninstall each of these, but nothing happened – they didn’t uninstall.

Trying to update the drivers on the network card (which said a file was missing) always give me the same error message: “The system cannot find the file specified.” It would almost work, up until the very end of the driver wizard, and then that error.

I found an article about running a Symantec tool called “Cleanwipe” that’s supposed to remove traces of failed Symantec Endpoint installations. You need an open support ticket to get it from Symantec directly, but if you know the filename, you can Google it and get it from others (note: I don’t vouch for the results – you’re on your own).

Running that tool didn’t solve my problem, though it did delete a number of components that were left. Next, I went through and manually deleted the remnants, following these instructions:

http://www.symantec.com/business/support/index?page=content&id=TECH91038&locale=en_US

That removed everything except the Teefer2 entries in my networking list. After about a dozen random fix attempts from all over the internet and reboots in between, I stumbled on an Experts Exchange question where somebody had posted a solution:

http://www.experts-exchange.com/Hardware/Networking_Hardware/Q_23508822.html

For those without access, the fix is simple – delete a single registry value. It’s located under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlNetwork and is called “Config”. Don’t delete the Network key, and don’t just clear this value, delete the value entirely. Once you do, you’ll be allowed to delete your network cards and the Teefer2 entries from device manager – remove all the Teerfer2 entries and any network connections that were associated with them, and then reboot. Windows will detect your network cards and let you install drivers, except this time it will work.

About 7 hours of troubleshooting and a dozen reboots, and the fix was to delete a single registry value. The Cleanwipe and the manual removal of SEP might have been required as well, but hopefully this saves you some time.

Dealing with an exception: “An attempt was made to access a socket in a way forbidden by its access permissions”

I was attempting to bind a remoting listening to a particular port and kept receiving an exception when attempting to bind on the production Windows 2008 R2 server itself – it always worked fine on both my development box and our test server. Here’s the exception:

Exception message: An attempt was made to access a socket in a way forbidden by its access permissions
Stack Trace:
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at System.Net.Sockets.TcpListener.Start(Int32 backlog)
   at System.Runtime.Remoting.Channels.ExclusiveTcpListener.Start(Boolean exclusiveAddressUse)
   at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object data)
   at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback)

Though Googling gave some suggestions to run the process as an administrator (no effect), the actual problem was that my process was trying to listen on a port that was already taken by another listener. Since the port was already in use, it couldn’t bind and I received the exception. Stopping the other process resolved the issue immediately.

Not really a clear error message, since it really had nothing to do with permissions at all, but there you go.