Have there been any changes around this in recent versions of WFA? My customer is seeing some timeouts when running some commands against busy snapvault secondary systems, and we would like to bump up the timeout values to see if that helps. Thanks,
You can also provide a -Timeout parameter to Connect-WfaController or Connect-WfaCluster:
It would be nice if there was a way to control the default timeout globally, since in many circumstances the timeout will occur in a certified command. One could dive in and edit WFAWrapper.psm1 but that seems slightly wrong
One of the underlying issues here is that 7-mode will only run up to 10 zapi commands concurrently, with subsequent commands queuing (up to some limit). So in a heavily accessed environment with many zapi commands running it's possible that any command could queue. So you really need to add the timeout globally and not just to specific long running commands (although that will help in many circumstances).
Any word on this feature yet? One issue I'm trying to contend with is that if any command is modified to include this timeout option the command itself is no longer certified which means WFA won't update its internal cache with the changes it makes. This is a challenge for our environments with a high rate of change.
For anyone else who is interested, I tried to insert a No-Op command at the beginning of my workflow that just connects to the cluster and calls out a specific timeout value. I did this because I noticed that subsequent commands would simply leverage the cached controller connection that the first command established. Alas, this appears to only be the case when the command that establishes the initial connection is also certified.
So I changed the default timeout by modifying the WFAWrapper.psm1 file which now works for all commands. Until we can certify our own commands or this variable is built into the commands in some way I see no other option while still being able to leverage the cache awareness that certified commands have.