Domain joined collector polling non-domain joined device
Hi,
I’ve been trying to resolve this for a few days now but no luck from an LM pov.
Collector is domain joined
Veeam server not domain joined
I’ve been through all the config. guides for WMI, DCOM, PSRemoting etc., AND from the collector itself I can now successfully get to the Veeam host using wbemtest with recurse option, and Enter-PSSession. However LM reports:
I’ve run the commands to check the WMI repository state and that comes back as OK. The Add Device Wizard did initially prompt for creds (but that’s because of my overall hierarchy setup so is expected), but on providing the creds for the local account it then succeeded with no other errors.
Then when it tries Active Discovery that error pops up.
What else am I missing? This specific code doesn’t have much info available from a Google; if I include LogicMonitor in the search I get 1 result, and that’s the general LM home page “get started” result.
Thanks
ldoodle
OP2 years ago@ldoodle I have had to wrestle with Veeam monitoring on a lot of diverse servers.
One step I’ve taken when the wmi properties are not aligned with a local admin is to add the local account as an Administrator within the Veeam console itself.
The other is to allow RemotePS between the collector and the Veeam server.
Yeah that’s basically how I have it now:
local account added to local admins group
local admins group is a Veeam Administrator role in Veeam itself
Jared Meidal
·2 years ago@ldoodle I have had to wrestle with Veeam monitoring on a lot of diverse servers.
One step I’ve taken when the wmi properties are not aligned with a local admin is to add the local account as an Administrator within the Veeam console itself.
The other is to allow RemotePS between the collector and the Veeam server.
ldoodle
OP2 years agoI have a forum post on various issues with non-domain joined and/or non-admin monitoring users at
https://community.logicmonitor.com/product-discussions-22/how-wmi-dcom-rpc-and-uac-effect-access-to-remote-window-systems-for-monitoring-2841
Okay, so after a lot of trial and error I just could not get it working without local admin rights. I followed all the guides, including the LocalAccountTokenFilterPolicy reg change in your post. Without local admin some of the classes were access denied. Now with local admin rights the only class with access in win32_service.
I still haven’t tried with UAC completely disabled and non-admin rights since that requires a reboot which I can’t just do.
Veeam server is 2022 OS so don’t know if anything has changed there.
ldoodle
OP2 years agoI 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.
ldoodle
OP2 years agoI am getting some data though. I can see graph data for Memory and Processes for example but CPU is empty.
ldoodle
OP2 years agoCollector 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.
Mike_Aracic
·2 years agoWhat’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?
LM User
·2 years agoIs it possible to check logs on the collector device to get some more meaningful info?
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.
Mike Moniz
·2 years agoYes 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.
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.
ldoodle
OP2 years agoIs it possible to check logs on the collector device to get some more meaningful info?
ldoodle
OP2 years agoJust 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.
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.
I have a forum post on various issues with non-domain joined and/or non-admin monitoring users at
https://community.logicmonitor.com/product-discussions-22/how-wmi-dcom-rpc-and-uac-effect-access-to-remote-window-systems-for-monitoring-2841
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.
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.
Mike Moniz
·2 years agoI have a forum post on various issues with non-domain joined and/or non-admin monitoring users at
https://community.logicmonitor.com/product-discussions-22/how-wmi-dcom-rpc-and-uac-effect-access-to-remote-window-systems-for-monitoring-2841that 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.
LM User
·2 years agoJust 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.