Not necessarily related to BI or SQL unless perhaps you are reporting on performance or software inventory, or using it for an ETL process. However, wmiprivse.exe is one of those important Windows mystery components that does a lot behind the scenes and is good to be aware of if you are a developer, and good to be an expert of if you are a support person. It also seems to come up often as a big consumer of CPU and memory. To me it always seems like a virus since it takes over my Windows randomly and pops up multiple processes, without any details on which application is generating them.
It really is quite a simple piece of software.
Well, not so much.
This article describes how to configure the component’s quotas to ignore some needless errors that some monitoring tools will throw.
When the WMI Provider service reaches its quota limit, WMI queries that are being handled by that instance of WMIPRVSE.EXE will most likely fail. However, there are applications like System Center that may require more memory or handles for the process. These quotas are configurable, however – do not modify these quotas for the sake of modifying them! If the WMIPRVSE.EXE process is actually leaking handles or memory, modifying the quota will only delay the issue from occurring, not eliminate it. In instances such as these, normal leak troubleshooting must be performed to identify the root cause.
More on WMI at Wikipedia.
And further on the (needless?) complexities of WMI.
Greg was quite enthusiastic about the power of Windows PowerShell but during the BOF someone asked him directly, "So which is it - should we be using VBscript or Windows PowerShell to script SMS". I forgot exactly what Greg said but it was along the line so of, "if you want to do reporting, use Windows PowerShell because it is very powerful but if you want to get things done, use VBScript because you can't invoke WMI methods (at least not easily)".
This was a real wake up call for us. Greg is exactly the sort of person that we want to be a ardent, unabashed, no reservations, hard core Windows PowerShell user and the message was loud and clear - almost but not quite.
We knew that our WMI support was not what we wanted it to be but as I've mentioned many times, to ship is to choose. We thought that we had reasonable support and that WMI users wouldn't be phased by some of the deficiencies - yes calling methods was complex but we figured that if you were using WMI, you were self-qualified as being able to cope with complexity :-) .
Kind of sad that an MS team ignored implementing functionality with WMI because they had issues with the complexity of their own product. Perhaps changing the names and methods for Windows Management Instrumentation to something a little bit more obvious would help with that complexity. The WMI counters and naming conventions appear to come from the days of Windows 95.
WMI is a very powerful and sometimes misunderstood provider. Some of the useful functions:
1. Get drive space for all drives & computers on a network.
2. Perform a software/hardware inventory
3. Start and schedule remote applications
4. Reboot computers remotely
5. Read and consolidate event logs
Being able to right-click on a service or device to explore WMI properties seems the most obvious piece of functionality that was left out of Windows.
Perhaps it could be used as a BI tool, to better understand how your network is functioning and mine data on how drive space is used? Get started with mining data using WQL.
Some more recent info on using Powershell and WMI.
Enterprise Event Forwarding
SQL WMI Provider
Comparing WMI to SQL
WMI Event Watcher for SSIS
WMI Data Reader Task