none
WUA API Remote Access Fail RRS feed

  • General discussion

  • Due to the deprecation of MBSA, I am looking to script access to the WUA API to perform the same functions as MBSA.  I've got the script configured and it works great in a domain environment on my local machine as well as when I try to hit a server.  However, when I try to hit another workstation, I get the below error.  This process is running with a domain admin's credentials.

    $updatesession =  [activator]::CreateInstance([type]::GetTypeFromProgID("Microsoft.Update.Session",COMPUTERNAME))

    Exception calling "CreateInstance" with "1" argument(s): "Retrieving the COM class factory for remote component with CLSID {4CB43D7F-7EEE-4906-8698-60DA1C38F2FE} from machine COMPUTERNAME failed due to the following error: 800706ba COMPUTERNAME."

    From what I can gather, this is a permissions issue with remote launching/activation of the WUA Remote Access DCOM object.  However, when I compare the DCOM permissions on the server that runs successfully and the workstation that fails, they appear to be exactly the same.  Both systems have the same McAfee suite (Disabled on fail box for verification) and Windows Firewall is also configured the same.  I've verified logs of both applications that they aren't blocking/filtering as well.

    1.  Has anybody run into this issue before or have followup steps I could perform to further diagnose the issue.

    2.  Is it possible to run a DCOM access check prior to trying to access it.  Like Test-WSMan or Test-NetConnection….but for DCOM.

    I'm confident this issue is related to a setting in a GPO, but I don't know which setting I need to be checking and we have dozens of GPOs that aren't properly aligned, so it would be like trying find a needle in a haystack...without understanding what a needle is.

    • Changed type Bill_Stewart Friday, March 15, 2019 7:02 PM
    • Moved by Bill_Stewart Friday, March 15, 2019 7:02 PM Off-topic
    Saturday, February 2, 2019 5:42 PM

All replies

  • If the script works on one system but not another, then the issue isn't the script.

    As I'm sure you know, this forum is for scripting questions, not break/fix issues. Unfortunately we don't have the resources to help you track down what might be happening.

    If this is critical to your business, I'd recommend opening an official support ticket with Microsoft or hire an on-site consultant.


    -- Bill Stewart [Bill_Stewart]

    Saturday, February 2, 2019 6:24 PM
  • Microsoft updater needs its own permissions and the firewall must allow the connection.

    This is not a scripting issue so you need to find a better forum.

    I suggest searching for the error and try some of the possible solutions.  There are too many things that can cause this error and this is not a support forum.

    For an example see: https://support.accessdata.com/hc/en-us/articles/224592388-WMI-error-800706ba


    \_(ツ)_/

    Saturday, February 2, 2019 6:25 PM