AdvisorAdvisorJust 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
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.
