0x80070005 access denied for remote wmi using managementscope.connect to win 10 pro 1803 RRS feed

  • General discussion

  • Issue:

    We have a custom service using system.managementscope.connect to connect to a remote wmi to gather it’s system/hardware/software data.

    This service runs on a windows 1803 as Local System and adds the correct impersonation & authentication level and also sets the connection options with the local username & password on the remote target.

    This worked on target machines running windows 10 pro <= 1703 but started returning “access denied” on targets windows 10 pro >= 1803.

    Remark: This problem only occurs when a windows 1803 (or later) machine is trying to remotely connect wmi to another 1803 (or later) machine.

    We can simulate this malfunction using wbemtest.exe:

    We have a problem getting a windows 10 pro machine (both in domain and workgroup) to connect to remote WMI to a windows 10 >= 1803 target in a domain or a workgroup.

    Every time we try to access it, we get “access denied”.  This is related to the user executing the remote WMI connection.

    If this user does not exist on the target machine, the remote WMI connection will always fail with “access denied”, even when this user has been passed with the connection options. This has worked on targets with windows 10 <= 1703.

    We did our tests using wbemtest.exe with the same impersonation & authentication level as the target (configured using dcomcnfg.exe).


    Until 1703:

    Test wbemtest.exe with local user of remote destination filled in in the credentials section:

    Able to connect and retrieve data

    Starting from 1803:

    Test wbemtest.exe with local user of remote destination filled in in the credentials section):

    0x80070005 access denied


    We need to specifically find which LocalSecurityPolicy/Registry settings have been modified in 1803 which is blocking the remote WMI connects.

    We already tried disabling windows defender, modifying remote uac, LocalAccountTokenFilterPolicy (and rebooting) but none of these changes worked so far.

    • Edited by LSGDR Tuesday, November 13, 2018 8:16 AM
    Friday, November 9, 2018 10:13 AM

All replies

  • Access denied means that the program running under the context of a user account being presented as credentials to access a resource on the machine doesn't have the rights to use the resource.  
    Friday, November 9, 2018 10:58 AM
  • Hi DA924x, Thanks for your reply. Before the upgrade to 1803 this was working with the same credentials. I only upgraded the machine launching the remote wmi query and/or the target receiving the remote wmi request. I didn't change the user credentials nor their rights on either machine.

    The problem applies to 1803 (and later, also tested with windows server 2019 preview) and I'd need to find the specific LocalSecurityPolicy/Registry settings which are blocking the rights for these WMI requests.
    On 1703 and earlier, I think that the user on machine A requesting wmi connection is unknown on machine B and set to guest by default but the remote still WMI works because of the credentials passed in the user/password of the connection options.
    On 1803 and later, I read that guest access had been removed and that this could be the reason why it no longer works.

    I'm wondering how to undo this guest access being blocked or how to resolve it otherwise.

    • Edited by LSGDR Tuesday, November 13, 2018 8:34 AM
    Tuesday, November 13, 2018 8:33 AM
  • Although MSDN has paid support, I would look for paid support with MS Technical Support by phone. 
    Tuesday, November 13, 2018 5:27 PM
  • I have the same problem. I use scripts to get WMI data from my clients (Win 10 1803). The clients are in a Domain. My Admin computer is not a member of the domain. I use VB Scripts to get WMI Information of the Client computers. I use Domain Admin Credentials to get the WMI infos. After the upgrade from my Admin Computer from 1703 to 1803 it will bring "Access denied" Error. If i use a Win 10 1703 computer with the same credentials it will work without any problems.

    I use this tool to test the WMI Access: https://www.de.paessler.com/tools/wmitester

    It looks like a Windows 10 1803 bug. It's not a Visual Studio related problem.

    best regards - Foppel

    • Edited by Foppel Friday, November 16, 2018 10:52 AM
    Friday, November 16, 2018 10:47 AM
  • I can confirm we have the same exact issue.  Only started happening with 1803.

    I can also highlight that the issue only seems to occur when inputting alternate credentials.  If logged on to computerA with local userZ, I can read WMI data on computerB, so long as computerB has local userZ defined with the exact same username and password as it is defined on computerA.  The issue occurs only when trying to connect with a different user account that is only defined on computerB.

    The issue did not exist prior to 1803.  I can connect from a 1709 machine to the 1803 machine without issue using an account that is only defined on computerB.  But from an 1803 machine to another 1803 machine, it does not work.

    • Edited by drigley Wednesday, November 21, 2018 9:48 PM
    Wednesday, November 21, 2018 6:48 PM
  • Has anyone on this thread opened a case and if so can you post the case number?

    Alternatively …. if anyone wants to open a support case email me at sb-at-askwoody.com (change the -at- to @)

    Thursday, November 29, 2018 4:30 PM
  • Hello, i was trying to solve problem witch access denied from "Win 10 1803 Domain" to "Win 10 1803 NON-Domain" last 6 monts.

    Now i updated to Win 10 1809 - AND WMI starts working everywhere...

    Hope this solve your problems.

    Saturday, December 1, 2018 7:45 PM
  • When I use Paessler WMI Tester from my Win10 1809 client to access one of our Domain Controller as a domain admin via Remote WMI I get error 80041008 and get no access.
    Sunday, December 2, 2018 11:22 AM
  • My colleague opened a case last week, but I don't have the case number at the moment.  I'll see if I can get it, or at least I will post back here when I have more info about status.
    Sunday, December 2, 2018 4:33 PM
  • What version of windows is your domain controller running? It it happens to be a 2016 server core only 1803, you'll need to upgrade .

    During my tests I found that neither the sender nor the receiver (your DC) can run both 1803 at the same time for the WMI queries to work. Either one needs to be on a different version.

    1706 (workgroup) can query 1803 and lower (both with local and domain credentials)

    1809 can query 1803 and lower

    but 1803 can't query 1803

    Monday, December 3, 2018 8:37 AM
  • My colleague just informed me that after he opened a support case last week Microsoft acknowledged the bug.  They said they will be fixing it in a cumulative update soon.
    Tuesday, December 4, 2018 8:04 PM
  • Hello.

    I am an engineer in Japan.

    I reproduced and confirmed the same error in one of my two evaluation environments.

    Environment 1
    -----> It reproduced.
    OS: Windows 10 professional
    version: 1803
    Local account

    OS: Windows 10 professional
    version: 1803
    Local account
    Connection permission setting of  local account for dcomcnfg and wmimgmt
    disabling windows defender, modifying remote uac, LocalAccountTokenFilterPolicy (and rebooting) 

    Environment 2
    -----> It did not reproduce.
           Normally connected
    OS: WindowsServer2019
    version: 1809
    Local account

    OS: Windows 10 professional
    version: 1803
    Local account
    Connection permission setting of  local account for dcomcnfg and wmimgmt
    disabling windows defender, modifying remote uac, LocalAccountTokenFilterPolicy (and rebooting) 

    • Edited by zukkie777 Friday, January 18, 2019 4:23 PM addtional comments
    Friday, January 18, 2019 4:12 PM
  • Our environment had the exactly same issue on remote WMI between windows 10 1803 machines.

    And we test out today if we execute the powershell scripts via the remote WMI on windows 10 1809 machine (Source) to windows 10 1803 machine (Destination), it does work properly.

    Hope it helps to everyone.

    Meanwhile, waiting for the cumulative update from Microsoft if there is.

    Tuesday, February 26, 2019 9:49 AM
  • This still seems to be broken.  I have a really simple setup - Windows 10 Pro 1809 fresh install, not on a domain and just want to make remote WMI connections from other machines on the LAN.

    Using WBEMTest from remote machines, I get 'Access Denied' 0x80070005.  I tried all Impersonation Levels and even though the account name and passwords are mirrored on both machines, I tried entering the local account creds in WBEMTest and still get Access Denied.

    I allowed WMI through the Firewall, tried disabling the Firewall altogether. I turned UAC off.  I added the account (and even 'Everyone' in desperation) to have full control in [WMI Control] -> [Properties] -> [Security].  I tried this on the Root and CIMV2 nodes.

    In gpedit, I made sure Everyone was listed in the [Computer Config] -> [Windows Settings] -> [Security Settings] -> [Local Policies] -> [User Rights Assignment] -> [Access this computer from the network]

    In dcomcnfg.exe I gave my user account full permissions for Launch, Access and Configuration for WMI.

    I don't know what else I can do.  Any help please Microsoft?

    Tuesday, March 12, 2019 4:38 PM
  • The issue was fixed for 1809.  It only still exists in 1803.  The issue you are likely encountering is that when using local accounts NOT on a domain for making WMI connections you would need to add the LocalAccountTokenFilterPolicy registry DWORD on the target computers, as described below.  Also I would suggest you start with the account being added to the local administrators group on the target computers too, and get it working with that configuration first.

    Essentially for LocalAccountTokenFilterPolicy it boils down to creating this DWORD and setting it to 1:


    You can google LocalAccountTokenFilterPolicy to find more on this topic.

    Wednesday, March 13, 2019 6:11 AM
  • Thank you! This worked!
    Wednesday, March 13, 2019 1:51 PM
  • I have been banging my head against this one for a few days now. I just wanted to add to this solution that while yes it is fixed in 1809 make sure that the computer that you are trying to execute the remote wmi FROM is also on 1809. My target systems were all 1809 but My management system was still on 1803. I have tried adding the registry value LocalAccountTokenFilterPolicy = 1 to the target systems as well as the registry value FilterAdministratorToken = 0. I checked to make sure the permissions for administrators were correct on the Windows Management and Instrumentation object in dcomcnfg. I also verified that the permissions were correct on the Root and CIMV2 namespaces in the WMI Conrol. IF YOUR MANAGEMENT SYSTEM IS STILL ON 1803 REMOTE WMI TO A COMPUTER THAT IS NOT DOMAIN JOINED WILL FAIL. There is no fix except to update to 1809.
    Friday, April 26, 2019 8:52 PM