Troubleshooting - MS SQL Server - Cannot connect to WMI provider. [0x8004100e]
Problem:
I ran into a strange error today. I attempted to launch SQL Server Configuration Manger on a server deployed in Azure, and I was greeted with an error dialog that implied either the server was unreachable or that I didn’t have rights. The error read, “Cannot connect to WMI provider. You Do not have permission or the server is unreachable. Note that you can only manage SQL Server 2055 and later servers with SQL Server Configuration Manager. Invalid namespace [0x8004100e].” After a bit of digging, I found a solution, and possibly even a root cause.
Background:
I thought the error was especially strange as the server was deployed using a Microsoft template from the Azure Marketplace. I deployed the SQL Server 2016 SP2 Developer on Windows Server 2016 template. There was a great deal of doubt that a Microsoft provided template would be defective in some way.
Fix:
I needed to run the SQL Server 2016 version of SQL Configuration Manager instead of the SQL Server 2017 version. As it turns out, there are multiple versions on the server.
A glance of the menu shows multiple application groups on the machine with SQL Server components.
Expanding the view shows the version of Configuration Manager to execute.
Root Cause:
At some point not too long ago (I believe it was with SQL Server 2017), Microsoft decoupled SQL Server Management Studio from the SQL Server install. This allows for newer versions of SSMS to be released at a faster cadence. The SQL Server 2016 Template in Azure comes with this newer version of SSMS. When SSMS is installed, it also comes with a lot of other utilities, including SQL Server Configuration Manger. This results in two versions of the SQL Configuration Manager installed on the same machine. Each one uses files in a directory names after the version number of SQL Server it supports. Based on some reading of various other blog posts for troubleshooting the error, my guess is that the .mof file needed for the 2017 version wasn’t compiled and therefore doesn’t successfully run.
These multiple versions can create confusion on the part of administrators. Personally, it forced me to worked differently. I normally click on the search on the toolbar, then start typing the name of the app I wish to use. In this case, I need to be extra cautious as I could accidentally launch the wrong version. This isn’t a make or break, but it’s something I now need to be aware of when working on this server.
So there it is. The answer was a simple one. In this case, it was user error. While I like that nothing complicated was involved in he fix, I also feel a little silly for not catching it right away. Simply running the version that matched my install would fix the problem.