VBR 11a : Find-VBRViEntity Cmdlet does not retrieve any objects

[ThierryF]

Hello,

I just noticed Find-VBRViEntity does not retrieve any object back from Veeam,
whatever the args can be since I upgraded VBR from 10 to 11a ...

Any known issue ? Any idea ?

Thanks

Th

[david.domask]

Hi @ThierryF,

I just tested on my v11a lab, and had no issues.

Can you maybe show the parameters you set? Are you trying to get VMs based on tags by change? (originally in v11, it was changed to only return tags, but this was reverted later on since the previous behavior was quite desirable for many power users)

Any errors?

Basically, likely Support needs to review the situation, but if you can confirm the above first, we may be able to guide you.

[ThierryF]

Hello,

A short sample. None of these Find-VBRViEntity provide any result :

Add-PSSnapin -name VeeamPSSnapin
connect-VBRServer -server mvbr_server

Find-VBRViEntity -VMsAndTemplates
Find-VBRViEntity -DatastoresAndVMs
Find-VBRViEntity -Tags

foreach ($VM in Find-VBRViEntity | Where-Object {$_.Type -eq "Vm"} | sort-object -property name ) {
$VM.Name
}




PS C:\Users\fdhthr> Find-VBRViEntity -name "VMs and Tempalate"
WARNING: One or more errors occurred.

PS C:\Users\fdhthr> Find-VBRViEntity -HostsAndClusters

WARNING: One or more errors occurred.
Id Name Path
-- ---- ----
49500DBE-39E7-4A3E-A48B-3F995D1EFF63 Hosts and Clusters
4c87ec86-d2a5-42d3-947a-bbda43a984e2 vwpvc vwpvc



Thanks

Th

[david.domask]

Thanks for this, but looks like indeed some errors that need to be checked.

I strongly recommend reproduce the issue, note the date/time of your test and the exact query (we can check this in the logs but it's best to confirm it to avoid confusions), and then export logs as per https://veeam.com/kb1832; use the 3rd option and select the VBR server for the export.

A side note, I recommend against the Foreach loop you have there; it's possible that in your loop there is some goofiness with the pipeline; I would start with just:

Find-VBRViEntity |Where-Object {$_.Type -eq "Vm"}

Does it return anything? (also, sorry if it seems like a dumb/offensive question, but the Hypervisor added _is VMware_, correct? HyperV has its own Find-VBRHvEntity cmdlet)

[ThierryF]

PS C:\Users\fdhthr> Find-VBRViEntity |Where-Object {$_.Type -eq "Vm"}
WARNING: One or more errors occurred

I will take care to open a support ticket.

Yes, it is vmware only as hypervisor and afew physical Intel Windows servers, no Hyper-V in house to test.

Th

[david.domask]

Got it, just clearing the basics Then definitely we need a case, that warning is not expected.

[ThierryF]

Hello,

Troubleshooting a bit more from my side before opening ticket to fully doccument it,
I noticed the Find-VBRViEntity to correctly retrieve and list objects if cmd is started directly from VBR server side.

The same FindVbr-VIEntity fails to retrieve object when started remotely using "Connect-VBRServer -server"

Can you confirm the behaviour from your side ?

Thanks

Th

[david.domask]

Hi @ThierryF,

I could not reproduce from Remote Console; connecting with Connect-VBRServer works as expected as does the Find-VBRViEntity cmdlet, but please be sure to mention you only see this on the remote console to your Support Engineer, and provide the logs also from the Veeam Remote Console (should be under %localappdata%/Veeam folder, you can just archive that folder and provide that, noting the date/time of your test)

[ThierryF]

FYI : Logs from Powershell :

[22.05.2023 13:58:48] <17> Info Instance of 'FindVBRViEntity' was created with Id '2139a811f0284c04820db8706aafba49'
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] ------- Begin Processing of Veeam PowerShell -------
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] Running cmdlet: Veeam.Backup.PowerShell.Cmdlets.FindVBRViEntity
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] Running command name: Find-VBRViEntity
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] Cmdlet script name: , line number: 1, offset: 1
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] Cmdlet pipeline length: 1, position: 1
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] --------------- Command session out ---------------
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] ------- Processing of Veeam PowerShell -------
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] Executing license check...
[22.05.2023 13:58:48] <17> Info [2139a811f0284c04820db8706aafba49] Preparing parameters...
[22.05.2023 13:58:48] <17> Info VMWare hierarchy call from C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe
[22.05.2023 13:58:48] <17> Info VMWare hierarchy call from C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe
[22.05.2023 13:58:51] <17> Info [2139a811f0284c04820db8706aafba49] ------- End Processing of Veeam PowerShell -------

[david.domask]

Thank you for sharing, but as noted, we need this to be provided in your case please Right now this looks like an isolated issue for your environment, so the logs need to be checked by Support

[ThierryF]

Case #06080668

[ThierryF]

Got rid of the issue, seems an older VimService.DLL file still present in .NET sub-dir.
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\VimService\v4.0_9.0.0.0__bfd684de2276783a
No idea where it came from, but renaming VimService.DLL and restarting powershell
resumed Find-VBRViEntity Cmdlet.

Warm regards,

Th

[david.domask]

Hi @ThierryF,

I was about to post as soon as I saw a conclusion to your case, and glad that it was found, and thank you for sharing the answer.

For others, I strongly recommend to review such issues with Support before making any changes. The GAC is the .NET Global Assembly Cache and this is something that should not be adjusted lightly in most cases, so it's best to do with the guidance of Support.

[ThierryF]

Hello David,

Yes, just renamed VimService.DLL file for a test purpose and seeing I can toggle the issue on/off with or without the file,
I reset it with its original name awaiting support guidance.
I have 2 computers with same issue/fix.

Warm regards,

Th

[david.domask]

Hi @ThierryF, aha, but I guess my post was more for others that if they get a similar issue, the specific file or issue may be different in their situation; so they shouldn't just try the same file that you did as it might be quite different in their situation. Basically the issue is just that old assemblies were in the .NET GAC, and it needs to be checked _which_ is the old and outdated one.

So that's the main concern