The "Type" property of $server already reported as "VC" but I tried running it as you suggested, just in case.
Unfortunately, this didn't make a difference, or perhaps only a slight difference:
Can you tell us whether you're using remote console or accessing PS module locally on backup server machine? Also, if you input $env:PSModulePath in PS session, what does it show? Thanks!
I'm using the PS module on a different machine to the B&R server.
I just tried running the original commands locally (on the B&R server) and it works as expected.
$env:PSModulePath returns the following results.
Remote machine:
C:\Users\admin\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Modules;C:\Program Files\Veeam\Backup and Replication\Console\;C:\Program Files\Veeam\Backup and Replication\Explorers\Exchange\;C:\Program Files\Veeam\Backup and Replication\Explorers\SharePoint\;C:\Program Files\Veeam\Backup and Replication\Explorers\SQL\;C:\Program Files\Veeam\Backup and Replication\Explorers\ActiveDirectory\;C:\Program Files\Veeam\Backup and Replication\Explorers\Oracle\;C:\Program Files\Veeam\Backup and Replication\Explorers\Teams\
C:\Users\admin\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\Veeam\Backup and Replication\Console\;C:\Program Files\Veeam\Backup and Replication\Explorers\Exchange\;C:\Program Files\Veeam\Backup and Replication\Explorers\SharePoint\;C:\Program Files\Veeam\Backup and Replication\Explorers\SQL\;C:\Program Files\Veeam\Backup and Replication\Explorers\ActiveDirectory\;C:\Program Files\Veeam\Backup and Replication\Explorers\Oracle\;C:\Program Files\Veeam\Backup and Replication\Explorers\Teams\;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\Veeam\Backup and Replication\Console\;C:\Program Files\Veeam\Backup and Replication\Explorers\Exchange\;C:\Program Files\Veeam\Backup and Replication\Explorers\SharePoint\;C:\Program Files\Veeam\Backup and Replication\Explorers\SQL\;C:\Program Files\Veeam\Backup and Replication\Explorers\ActiveDirectory\;C:\Program Files\Veeam\Backup and Replication\Explorers\Oracle\;C:\Program Files\Veeam\Backup and Replication\Explorers\Teams\
I'm not sure why the path is duplicated here, but it seems inconsequential since it works fine.
I assume you connect to Veeam B&R Server, where Backup Console is installed alongside, from a remote machine using WinRM tools (New-PSSession, Enter-PSSession)?
So, you don't have Veeam Backup console installed on your remote machine, right?
No, I have the VBR console installed on the remote machine. As you may see above, C:\Program Files\Veeam\Backup and Replication\Console\ and the explorer paths are in the PSModulePath environment variable.
We are trying to reproduce your issue together with Dev team now. As this is a technical one, please, contact our support and share this forum thread with them. Don't forget to share the case id here as well.
In parallel, please, run the commands below on both your remote VBR console and local VBR server and post the output results.
Did you find a solution to this problem? I am experiencing the same error.
The command Find-VBRViEntity works fine when executed locally on the VBR server, but as soon as it's executed from a remote server, we get the same error:
We have been discussing this issue with QA and Dev for a while now.
It might be happening because assemblies of some Veeam services are not being updated on a remote VBR console machine when moving from v10 to v11. Hence, the difference between assemblies' versions on a remote machine and a local server might lead to such errors. I'll update this thread as soon as I have precise answers. Meanwhile, it might be worth submitting a case and sharing the number here for further tracking.
For anybody, who encountered this issue. This may happen due to assemblies not being deleted from Windows Global Assembly Cache upon VBR v9.x uninstallation. Since v10 we use a different location to keep them, but because of .NET CLR nature it still picks up these libraries from GAC. The solution is to locate outdated assemblies with the script I shared above, find them in GAC and delete from there. Due to the fact that outdated assemblies' names may differ from case to case, I'd recommend contacting our support team so that they could help you with locating the libraries and removing them from GAC. Thanks!
I have merged your post with the existing topic, where we discussed this issue a while back. Please, check the recommendations from my last post above.