Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.To learn more, read the FAQ and watch the video.Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.
System was reporting PowerShell Connection Timeout
Connection timeout at the Get-NcVol command: get-ncvol : Connection to FAS3220CB-m on port 443 for protocol HTTPS timed out. + get-ncvol + ~~~~~~~~~ + CategoryInfo : InvalidOperation: (FAS3220CB-m:NcController) [Get-NcVol], NaConnectionTimeoutException + FullyQualifiedErrorId : ApiException,DataONTAP.C.PowerShell.SDK.Cmdlets.Volume.GetNcVol
Increasing the $global:CurrentNcController.TimeoutMsec does not have any effect
We provided the following action plan;
Open an RDP session to the WFA server. Go to <InstallDirWFA>\netapp\WFA\PoSH\Modules\WFAWrapper Backup WFAWrapper.psm1 file to a separate location. Edit the original WFAWrapper.psm1 file. Change the timeout setting from [int]$Timeout=60000 to [int]$Timeout=300000 under the following three categories/functions inside the file: Connect-WfaCluster, Connect-WfaController, and Connect-Controller. Save the file.
another error after doing the steps;
In about 50% of script runs, I get this error on the Get-NcVol command: get-ncvol : API invoke failed. + get-ncvol + ~~~~~~~~~ + CategoryInfo : InvalidOperation: (FAS3220CB-m:NcController) [Get-NcVol], NaException + FullyQualifiedErrorId : ApiException,DataONTAP.C.PowerShell.SDK.Cmdlets.Volume.GetNcVol
The Connect-NcController command always works without troubles. On three other filer, the script is also running without errors all the time.
why changing timeout settings on the WFA server had any effect. Do you have an explanation on this? Or is it possible only through the adaptation in the script?
Have you try explicitly increasing the timeout within the WFA credentials for the clusters that are erroring? In WFA click on the Execution tab, Click on Credentials in the left navigation menu then select the cluster and click "override defaults" and update the timeout values. EG
This isn't a definative answer, just a troubleshooting suggestion. There are a number of issues that might be causing your timeout, network latency, routes, firewalls etc.
It's difficult to say without knowledge of your environment. Do the systems that timeout have a high volume count? Are these systems under a high workload?
Are you able to replicate the issue (externally to WFA) in a powershell script?
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
The point is, we do not use WFA in this system and any changes to it should not have effect on PowerShell Connection Timeout. This is the question; why changing WFA has solved the PowerShell Connection timeout?
I am fimiliar with this case. Changes to the WFA obviously had no effect. The script just worked a few times after the WFA changes by accident . Afterwards, however, there were very often the connection timeouts again. The idea, that it has something to do with the WFA was basically a misunderstanding. In fact, it has always been a simple PowerShell script, which is started by any client or host.
Unfortunately, this problem still exists. Are there any solution ideas that could be followed?