I am having trouble getting the windows update sensor to work with a non-administrator account - I get the following error: Creating an instance of the COM component with CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE} from the IClassFactory failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

If I add the user account to the Administrators group on the server then the sensor works fine, but for obvious reasons I do not want my account to be a member of the administrators group. I am using Server 2012R2.

My testing so far:

According to the article at https://helpdesk.paessler.com/en/support/solutions/articles/76000042368-problems-with-windows-update-status-sensor, a key part of the powershell script is 'New-Object -ComObject Microsoft.Update.Session'.

I can run this piece of code successfully in a non-administrator user account when logged on to an desktop session such as my personal user account. However I cannot run this code successfully when running the code in a remote powershell session using the same user account.

The code does run successfully in a remote powershell session for an administrator account.

So, what specific permissions to I need to add to my account to be able to successfully run this in a remote powershell session? Anyone else have this scenario working?


Article Comments

Hi mpnzhc,

Is the user you're trying to use a member of the Distributed DCOM Users group?


Kind regards,
Stephan Linke, Tech Support Team


Aug, 2017 - Permalink

Yes, the account is a member of both Distributed DCOM Users and Performance Monitor Users.


Aug, 2017 - Permalink

I have come to the conclusion that the user must be a member of the administrators group. https://msdn.microsoft.com/en-us/library/aa387288?f=255&MSPPError=-2147217396


Aug, 2017 - Permalink

And it works now? :)


Aug, 2017 - Permalink

No, I do not want to elevate my probe account to an administrator. I have implemented an alternative solution to using this sensor, involving running a scheduled task on the target machine and fetching the results using remote powershell.


Aug, 2017 - Permalink

That's what the new update sensor will do basically. The workaround is only temporary then :) Please keep an eye on https://www.paessler.com/prtg/history/stable to see when it's released shortly.


Aug, 2017 - Permalink

Long shot on this one, but mpnzhc, I'm running into the same problem. Powershell remoting to call Windows Update API requires local admin on the destination server, https://docs.microsoft.com/en-us/windows/win32/wua_sdk/using-wua-from-a-remote-computer.

Would you be willing to share your solution scripts?


Feb, 2021 - Permalink

Hi Randy, I never actually implemented this - what I was going to do was schedule a task to run Get-WindowsUpdate (from the PSWindowsUpdate powershell module), dump the results to csv and pick them up with with the custom sensor. Now that you've reminded me I might give it a crack later today.


Feb, 2021 - Permalink

Hello Dear customer

I have not seen this to be proposed on this latest version. It will be awsome if you can elevate a feature request by following this article https://helpdesk.paessler.com/en/support/solutions/articles/76000063572-how-can-i-propose-new-features-or-sensors-for-prtg


Sep, 2022 - Permalink