Get-VBRReplica will wait for a long time if you have a Veeam Cloud Connect Provider added but it's unreachable for any particular reason.
If the VeeamPowershell.log file is really tracking the powershell activity, I can see that it's because when executed, the cmdlet looks to have a function that tries to poll the Provider, presumably for Cloud Connect Replicas. I only noticed this as I was working on some script on our test box which had a defunct provider we no longer were testing with still added. I can see this happening when a provider is having issues for example or if there's a routing issue, etc, and it's just a bit black-boxish and unpleasant.
As I see it, it's how the cmdlet is supposed to function (it fetches all replicas after all), so doesn't seem to be a bug at all, just an undesirable situation, and maybe there's a bit of a better solution than such a long hang?
Some thoughts:
- Make Cloud Connect Replicas a parameter not as default behavior; this seems most reasonable for me as even if the connection was live, I don't really want to add the wait for info on the Cloud Connect Replicas if I don't have to and I don't want to have to pipe the output to exclude Cloud Connect Replicas if I just want local ones.
- Revisit why the connection to the provider is necessary on the Get-VBRReplica stage; I would imagine that the relevant data necessary at the time of the cmdlet should be no more than a simple database entry (Status, number of RPs, etc, should all be there)
- Greatly shorten the timeout on connecting to the provider; if it must stay, then we can shorten this for sure? If it's not responding in like 30 seconds, return unavailable by default and include a -WaitForProviderTimeout parameter or something so we can decide what is a reasonable amount of time before declaring the provider unreachable.
All things being equal, I think just separating Cloud Connect Replicas out to a parameter would be best to limit the scope of the cmdlet.