Lovely post title, and a very annoying error.
I ran into this error while trying to communicate with Windows Management instrumentation in order to get the PathName installation parameter of the MSReportServer_ConfigurationSetting class (which hooks up to a Report Server instance). The issue is a very vague COM exception that doesn’t really give much information, what made the issue worse is that it is not a connection issue to the WMI Namespace, which works absolutely fine, the issue happens when my code tries to load any data from the namespace that I already successfully established a connection to.
In this post I will be giving a very brief introduction into WMI for Reporting Services, the reason this issue was happening, and how I managed to resolve this issue for my particular case.
Without going into too much details, WMI (or Windows Management Instrumentation) is a service that allows you to programmatically query and manage different aspect of the Windows OS system, so for example you could query what process are currently running, what are the available disks on the machine, etc.
WMI can report on Reporting Services (SSRS) and allows users to query ConfigurationSettings as well as some basic information regarding the instance of SSRS. There are two supported classes:
- MSReportServer_Instance Class
- MSReportServer_ConfigurationSetting Class: The one I am using for the purpose of finding out the SSRS installation path.
Now my code was essentially calling the ConfigurationSettings class in order to find out the installation PathName for a particular instance of SSRS, the code was working fine on our servers until we migrated to a new environment that caused the following error message:
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
To cut a long (and painfully annoying to debug) story short, in my case this was a security issue, I managed to test this by writing a small console application that implements the connection to the SSRS WMI which I then ran once in a Commandline that has not been elevated to Admin, and another that has been elevated to run as Administrator, the elevated access one worked fine.
So, since its a security issue, in order to resolve the issue I followed these 2 steps:
- The first thing to do is make sure that whatever user account is running the WMI implementation has the rights to access WMI services and COM/DCOM objects: I found an article that goes through enabling WMI access for non-admin domain users. Although the article is related to Splunk (logging solution) setup, it is still applicable to any user that is trying to access WMI services. Although in my case the account was setup with all the relevant security features needed to run WMI.
- Disable UAC (User Control Access): This is actually what worked for me, for some reason even though the account has all the relevant access rights, it still could not execute the WMI script without throwing the error above, disabling UAC will essentially mean that everything will run under the highest privilege, which is exactly what I needed.
So this basically solved the issue, and the WMI service can be queries no problem now, but the solution is not very elegant, since disabling UAC might be considered a system vulnerability, the better way is to ensure that whatever application you have accessing WMI is doing so with the elevated privileges, in my case that was not possible.
One last thing to note here, in order to quickly connect to a WMI instance (locally or on a remote computer), run queries or even edit/update values, you can use the built-in windows tool WBEMtest, which can be reached by clicking on the Start menu, then click on Run and type WBEMtest, very handy if you just want to make sure everything is on the up and up.
WMI Error: System.Runtime.InteropServices.COMException (0×80040208) rated 4 out of 5 by 1 readers