Domain joined collector polling non-domain joined device

Just to be clear, on the veeam resource in LM, you’ve set wmi.user and wmi.pass to be the username and password of the veeam box, right? Since the target is not on the domain, if you don’t provide those, it will try to use the credentials of the account running the collector service on the collector. Since the collector is on the domain, those credentials won’t work. So, you have to provide the credentials of the veeam box on the veeam resource in LM so that the collector uses those instead of the collector’s identity itself.

I have a forum post on various issues with non-domain joined and/or non-admin monitoring users at

that might be useful to look at. Is the local user you setup local admin? Might want to try that, even if it’s just for a test.

Also try using the IP address in LM instead of the fqdn (or vica versa). If the reverse dns/ptr record for the veeam server is wrong, wmi will reject using the fqdn.

Yeah, you would need to use that. I’m pretty sure I’ve mostly been able to use .\localaccount in wmi.user but I would try all of them. In theory if the local user’s username and password is EXACTLY the same as the domain one, it should work without wmi.user/pass but I normally would use wmi.user/pass.

Might be worth checking the log on the collectors, but in my experience what you showed in your screenshot is generally all you get from wmi itself. I would check on the Security Event log of the Veeam server though as it might provide additional details.

You can use !tlist in the collector debug to see what’s going on with the collector task. But it’ll show only little more than the poll now does.

What’s the service account that the collector and watchdog are running under? What do you get when you run the !account command in the collector debug? Is that the same one you’re using when you use wbemtest?

I have managed to get it putting events in the WMI log and this is what I now see - I get lots of these as it’s trying to read each class.

Id = {00000000-0000-0000-0000-000000000000}; ClientMachine = <collectordevice>; User = <remotemachine>\<localaccount>; ClientProcessId = 7272; Component = Unknown; Operation = Start IWbemServices::ExecQuery - ROOT\cimv2 : SELECT * FROM Win32_NetworkAdapterConfiguration; ResultCode = 0x80041004; PossibleCause = Unknown

Some of the show the result code in bold, others swap it out for 0x80041003, which is usually ‘access denied’. I currently don’t have UAC disabled. It is successfully using the creds in wmi.user and wmi.pass, with the .\ prefix.

The local account is currently a member of local Admin group.

Yes I did try that initially. However, since it’s a local account on a remote system do I need to specify the machine name in the wmi.user property? e.g. .\<localaccount> or <localmachinename>\<localaccount> or even <localaccount>@<localmachinename> similar to @vSphere.local ? I’m sure I tried one of these also but can’t remember which.

For things like this I usually add to local admins first to prove it will all work then wind back perms. It was the same issue as local admin.

Is it possible to check logs on the collector device to get some more meaningful info?

Collector service account is SVC_LMMONITOR, and in this case the local account on the Veeam server actually does match the collector service account, both username and password.

I haven’t tried anything on the collector debug yet but I will.

And yes, the account in LM is the same as I used for wbemtest and Enter-PSSession.

I am getting some data though. I can see graph data for Memory and Processes for example but CPU is empty.