Configuration Manager is Corrupt

Categories: News, Professional, Security, SSC
Comments: 1 Comment
Published on: December 17, 2019

The longer one works in the IT industry, the more likely it becomes to experience a broken system in some capacity. One minute it is working and the next it is not. This is true even of systems that are properly maintained and secured. Stuff happens and pieces break here and there.

I had the distinct pleasure of experiencing this exact problem. One of the essential tools in the DBA tool chest is the SQL Server Configuration Manager. Usually everything works fine here – until it doesn’t. This is a critical component to a well configured server. If nothing else, a DBA should be well enough versed to know that services for SQL Server should be bounced and configured from here. If you were unaware of that requirement – you now know.

Lesser known is the fact that this tool uses WMI to view or change various server settings. WMi allows for a uniform method for the interaction with these services and configurations. Almost all of the time, that is a seamless interaction and the DBA is none the wiser. And then it doesn’t work and the DBA grows more grey hairs.

WMIPY Issues

So you come along one day to validate some service configurations for the SQL Server services and instead of the SQL Server Configuration Manager opening as expected, you are greeted with the following error message.

Cannot connect to WMI provider. You do not have permission or the server is unreachable. Note that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager. Invalid namespace [0x8004100e]

Your first thought might be that the issue is being caused by UAC. So you try to run the SQL Server Configuration Manager as administrator. Sadly, that attempt resulted in the exact some error.

What to do? What to do?

Well, the problem is that the WMI provider has become corrupt or removed somehow. This problem can occur whether you have uninstalled a SQL Server instance or not (e.g. some documentation suggests the root cause for this problem is only if you uninstall a SQL Server instance). For me, this issue has arisen many times and never has an Instance been uninstalled. No worries either way because the solution is simple – run a statement similar to the following.

There are two caveats with this script execution: 1) you must run this from an elevated command prompt and 2) you must replace “VERSIONNUMBER” with the correct version number matching your version of SQL Server from the following table.



Microsoft SQL Server 2005


Microsoft SQL Server 2008 R2


Microsoft SQL Server 2008


Microsoft SQL Server 2012


Microsoft SQL Server 2014


Microsoft SQL Server 2016


Microsoft SQL Server 2017


Microsoft SQL Server 2019


If you execute this command and see an error with this code in it (0x80041003) then you have not executed the command with adequate permissions or elevation. You may need to find an administrator for the box and/or execute from an elevated command prompt (e.g. “Run As Administrator).

The Wrap

This article took a look at a rather annoying little error that can crop up out of the blue when trying to open the SQL Server Configuration Manager. Not only do we get to see that error and the cause, but we also get to see an extremely easy fix for the problem. Employing this easy fix will have you back in business administering the SQL Server services in the proper fashion in very short order.

This has been another post in the back to basics series. Other topics in the series include (but are not limited to): Backups, backup history and user logins.

page 1 of 1

December 2019
« Nov   Jan »

Welcome , today is Saturday, June 6, 2020