Lost WMI connections Windows 10 Pro

I asked something like this earlier but didn't get a working solution:
This is on a peer-to-peer network - so no Server and no global GPOs.  All of the settings have to be on individual workstations.
We're using ManageEngine EventLog Analyzer (ELA) for SIEM which uses WMI for workstation monitoring.
All of the workstations, including where ELA is running are Windows 10 Pro.
In the past, I had ALL of the computers being monitored successfully.
Over time, the number of computers which "connect" at the monitor computer has dwindled to around 50% - so something has changed.
The change must be on the computers being monitored because half of them still work fine at the monitor end.

To simplify the question, let's stick with the results from WBEMTEST and forget about ELA for now.
It appears that all of the recently "disconnected" computers will no longer connect using WBEMTEST.  I know this is more widely known and documented.

I originally created a checklist and a script to make most of the workstation settings.  Using them no longer allows successful connections.
All of the workstations are now at Windows 0 Pro 1709 16299.309.
So why do some work and others not work?  I've not found a common thread.

Lately, I've taken to trying various PowerShell inter-computer commands to see if that might shed some light.  So far, no joy.
I've tried WMIC commands such as
cpu get systemname
For a computer that still connects, I get a valid response.
For a computer that no longer connects, I get "Access is denied".

I'm looking for a near-term solution for this peer-to-peer network; not a longer-term Server-based approach for now.
Any suggestions would be greatly appreciated!
LVL 27
Fred MarshallPrincipalAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Krzysztof KubiakWindows Server AdministratorCommented:
Hello Fred

When you say:

"I've tried WMIC commands such as
cpu get systemname
For a computer that still connects, I get a valid response.
For a computer that no longer connects, I get "Access is denied".

Do you mean that you logon to the not working machine and Can't run the query locally? The answer depends from next steps as if it works locally we can rule out a lot of stuff.

This where I would start looking and comparing settings between the working and not working PC

DCOM
Open Dcomcnfg, Expand Component Service -> Computers -> My computer
Go to the properties of My Computer
Select the COM Security Tab
Click on "Edit Limits" under Access Permissions, and ensure that the account youare trying to run it is there (In a lot of cases Companies use Everyone. If you use Everyone make sure this group has required permissions - however I would suggest to use PRivileage accounts)  has "Local Access" and "Remote Access" permission.
Click on the "Edit Limit" for the launch and activation permissions, and ensure Everyone/ OR AD group or account  has "Local Activation" and "Local Launch" permission.
Highlight "DCOM Config" node, and right click "Windows Management and Instruments", and click Properties.
Compare the  Launch and Activation Permissions, Access Permissions, Configuration Permissions settings.

WMI:

Open WMImgmt.msc
Go to the Properties of WMI Control
Go to the Security Tab
Select "Root" and open "Security"
Compare Permissions

Check if there are difference in UAC settings. (Don't recommend as a Solution to disable UAC but its worth to check)

At the end I would review this url:
https://community.spiceworks.com/scripts/show/181-resolving-spiceworks-unknowns-unofficial

Maybe the script will help you, but I would try it on a Test machine first.

If you find this solution helpfuul please mark it, so others can find it easly.
0
Fred MarshallPrincipalAuthor Commented:
Thank you!!

It works locally.  Remotely gets "Access is denied"

To remind: this is working on at least half of 50 machines which have all been set up according to a checklist of manual settings and using a script that does most of what's needed.
0
Krzysztof KubiakWindows Server AdministratorCommented:
Hello Frank

Ok then lets try to go to the bottom of that.

If it works for 50 machines and the machines where its networking are on same VLAN/ Network then we can rule out at least Firewall.

There must be something on the loca PCS then.

From th 50 machines we need to take 1 machine where its working and the second where its now.

Is it also possible to take the piece of code from your SIEM which is failing or will that that command be sufficient to test:
WMIC /node:IP Address /user:username /password:password cpu get systemname

or with powershell

$credential = get-credential

Get-WmiObject -Class Win32_OperatingSystem -ComputerName IPAddress -Credential credential

We need basically a command which will fail on the not working one and will work with the working one.

When we get that following I would suggest to check


1. First still check the permission as mentioned before on DCOM and WMI, as there is a special setting to allow Remote Connection. Try to add a account which you can use on the above scripts so you can make sure that the account used for SIEM has right permission
Same as here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/4f33837b-1cb1-4648-85b1-3ba87cbfe93e/wmi-remote-access-denied?forum=winserverManagement
You need to compare the settings with a working machine, and not working machine
2. Run the command against the not working server and check in Event Viewer the Security logs, and application logs. The Security logs should show any failure.
Do same for a Working one so you can compare.
3. Check Windows Firewall on the not working Device. If you use Windows Firewall try to disable it for a moment and then test
4. Install Wireshark on the Source PC from where you testing. Start Capturing the traffic and reproduce the issue. Then Capture an additional log and do the same query on a working machine:
      - Filter Wireskark by ip.addr == IPaddress and see if you can spot any differences, in special with SMB traffic. You need to start-stop logging in wireshark very closely when yu run the command as you might see a lot of logs.
      You can PM me the logs. Better then attaching it to the Correspondance as it might give a lot of details out.
      
      
5. When you run the wmi command by using powershell or wmic does it constantly not work on the not working machines or is it from time to time only.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Fred MarshallPrincipalAuthor Commented:
Thank you!!

I believe that the problem is solid.  I've not seen anything else.

As far as checking settings, I've been doing that on targeted machines and have found nothing wrong.
AS HAS the SIEM software provider in remote sessions.
Also, I've added some settings based on people trying to help.
In truth, I rather feel that their experience is one of throwing things at the wall to see what sticks.

The targeted machines can have their firewalls turned off with no help there.

I'm attaching the current manual settings instructions.  Perhaps you will see something that you've already asked about.  
We also have a script that makes many of the settings that are listed - except perhaps the DCOM settings.

In the mean time, I'll try to run the Wireshark but from another machine (to control traffic content) that demonstrates the same results using WBEMTEST or WMIC or both.  I'll filter the display to focus on one target interaction at a time.
WMI-Setup-for-Workstations-Rev-2.doc
0
Krzysztof KubiakWindows Server AdministratorCommented:
Hi

The options I mention from your Document is this:

DCOMCNFG.EXE
Computers / My Computer / DCOM Config / Windows Management Instrumentation" //
Properties / Security / Launch and Activation Permissions:
… add “[user]” with full privileges
Computers / My Computer // Properties / COM Security
Access Permissions and Launch and Activate Permissions
"Edit Limits" for both sections. add “[user]” with full privileges  

If "add “[user]” with full privileges  " measn that you are adding a user and giving all permissions then it should be ok.

Also with you Windows Firewall. When you disable the Windows Firewall only disable the State never the service. But I presume you did that so that's ok also.

And i understand what you mean with " throwing things at the wall to see what sticks."

At the moment what we already checked is that your settings are fine, and there shouldn't be any firewall issues.

Wireshark should give us some information, but sometimes it might not provide us the solution. Anyway go ahead with Wireshark.

Some other things which I would check:
On the affected server if the Windows Management Instrumentation (Winmgmt) or if it's not throwing any errors in Event Log.
Whenever you building a connection did you checked also the Even Log (Security, Application) if it's not thworing any erros:

Opposite Wireshark I would also try to use the Diagnostic tool describe here:

https://blogs.technet.microsoft.com/askperf/2007/06/22/basic-wmi-testing/
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Fred MarshallPrincipalAuthor Commented:
The WMIDIAG generates what look to be very useful results.  Thank you!!

With this, I found two new settings that aren't on my setup list or in the script:

Firewall rule:
Windows Management Instrumentation (WMI-Out)

Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy
Needs to be presesnt and value set to "1" Disabled.

Dealing with these seems to help.  I got most the of machines connecting this way.
However, now it appears that many of the machines that were working have "fallen out".  ????? That seems very strange to me.

I see this on all the computers whether they work or not (so haven't focused on it) but I haven't deciphered what action I must take to fix it:
 WARNING: WMI provider DCOM registrations missing for the following provider(s): ..................................... 2 WARNING(S)!
37155 08:05:31 (0) ** - ROOT/STANDARDCIMV2/EMBEDDED, WEMSAL_WmiProvider ({ABB3FBAD-CFBB-41C6-8CD2-72F52EA60ADB}) (i.e. WMI Class 'WEMSAL_AppXInformation')
37156 08:05:31 (0) **   Provider DLL: 'WMI information not available (This could be the case for an external application or a third party WMI provider)'
37157 08:05:31 (0) ** - ROOT/MSAPPS12, OffProv12 ({DBF82DC7-E750-4CCF-B09C-D8AECEF7158E}) (i.e. WMI Class 'Win32_PowerPoint12Tables')
37158 08:05:31 (0) **   Provider DLL: 'WMI information not available (This could be the case for an external application or a third party WMI provider)'
37159 08:05:31 (0) ** => This is an issue because there are still some WMI classes referencing this list of providers
37160 08:05:31 (0) **    while the DCOM registration is wrong or missing. This can be due to:
37161 08:05:31 (0) **    - a de-installation of the software.
37162 08:05:31 (0) **    - a deletion of some registry key data.
37163 08:05:31 (0) **    - a registry corruption.
37164 08:05:31 (0) ** => You can correct the DCOM configuration by:
37165 08:05:31 (0) **    - Executing the 'REGSVR32.EXE <Provider.DLL>' command.
37166 08:05:31 (0) **    Note: You can build a list of classes in relation with their WMI provider and MOF file with WMIDiag.
37167 08:05:31 (0) **          (This list can be built on a similar and working WMI Windows installation)
37168 08:05:31 (0) **          The following command line must be used:
37169 08:05:31 (0) **          i.e. 'WMIDiag CorrelateClassAndProvider'
37170 08:05:31 (2) !! WARNING: Re-registering with REGSVR32.EXE all DLL from 'C:\WINDOWS\SYSTEM32\WBEM\'
37171 08:05:31 (0) **          may not solve the problem as the DLL supporting the WMI class(es)
37172 08:05:31 (0) **          can be located in a different folder.
37173 08:05:31 (0) **          You must refer to the class name to determine the software delivering the related DLL.

Open in new window

I see:  Executing the 'REGSVR32.EXE <Provider.DLL>' command but don't have the "provider.dll" specifics or, if tried, didn't work.  I don't recall which.  Part of the issue here is finding the .dll - which I've not even guessing at the name.

Thank you!!
0
Fred MarshallPrincipalAuthor Commented:
Thanks!  I've been away from this for some time so decided to close the question and award the points.  I'm sure I'll have to get back to it eventually.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
WMIC

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.