I am running a custom workflow to create volumes that has worked since WFA 2.x, and which works well in 3.0P1. With WFA 3.1RC1 it throws this error when attempting to apply a quota to the volume:
INFO [Apply Quota Policy to Volume or Qtree] Started Quota resize on volume post_wfa31rc1_test2_w_mirror on vserver MySVM
ERROR [Apply Quota Policy to Volume or Qtree] Command failed for Workflow 'Create Volume (Schwab)' with error : Object reference not set to an instance of an object.
INFO [Apply Quota Policy to Volume or Qtree] ***** Workflow Execution Failed *****
I have executed the PS commands from this code block in a PS shell with no errors. Has anyone else seen a similar issue with 3.1RC1?
Your inconvenience is regretted.
Now to debug this, can you provide the workflow dar file? Or atleast the command .dar file. you may mail it to sinhaa at netapp dot com if you don't want to post it here.
I am currently working with Dave Korns on this issue. If he is unable to resolve it, or if he wishes to have you work in parallel or in collaboration, I will be glad to email you the workflow. Thank you so much for the kind offer.
I have narrowed the problem down to a single command and can reproduce the problem very easily. However, I can't seem to fix it. But I believe importing this single custom command into both a WFA 3.0P1 and WFA 3.1RC1 system will easily show that it works in 3.0P1 and throws the odd 'Object reference not set to an insance of an object' error. I say that is an odd error because I'm only used to seeing that error at Preview time referring to an object reference in a Command Parameter field of a workflow. I know how to deal with that issue.
However here, the error appears at the end a PowerShell command. Actually, the PowerShell command appears to me to execute entirely and correctly. It is just that at the end of running this exception error is thrown and that causes the command (and workflow if running within a workflow) to fail. But the comamnd correctly adds the 'default' quota policy to the volume and even enables quota resize as it should. So it works, but still blows up the workflow it is within.
I'm going to attempt to attach these three things here:
1) screenshot showing the command running (with Command Test Button) fine under WFA-3.0P1,
2) a screenshot showing the command running but throwing the error on a WFA-3.1RC1 system
3) the ,dar file holding just the command: "Apply Quota Policy to Volume or Qtree" (I added .txt to the end of .dar file name)
1) running OKay on 3.0P1
2) running with the ERROR on WFA 3.1RC1
My lab environment where I re-created the problem:
The WFA 3.0P1 system is a Windows 2008R2 server that happens to have the original PowerShell 2.0 on it
The WFA 3.1RC1 system is a Windows 7 system that I have updated PowerShell to 4.0.
The customer environment:
I'm less certain of details (maybe Scott can fill in)
The version of PowerShell is TBD (guessing 2.0) , but they are running the same PS version for both 3.0P1 and 3.1RC1 because they are upgrading/downgrading WFA on the same system
The version of PowerShell on my Winders host is 4.0, and it's running Server 2012 R2 Standard. I note that WFA 3.1RC1 won't install unless you have at least PowerShell 3.0.
I want to take this opportinity to thank everyone that is pitching in help with this issue. I am delighted that it is reproducable by others, as that means it's not something odd that is specific to my environment.
The problem has been identified and I've also got the fix for it. Right now testing it.. The solution will be sent to you via email along with the details of the problem.
ONTAP PSTK fix may not be available soon. So you have to modify your command code to handle this. -ErrorAction SilentlyContinue is okay but it will even silently continue with genuine errors. We don't want this.
We scpecifically want to silently Continue for this error and this error only. So modify your code with the below logic
##Use the below
-ErrorAction SilentlyContinue -ErrorVariable myError
if (!($myError -Match "Object reference not set to an instance of an object."))
This will throw all kinds of exceptions but will continue for our "Object reference not set to an instance of an object" withut any issues.
Thank you. unfortunately still it errors out with "Object reference not set to an instance of an object". I tried using -EA SilentlyContinue.
I've mail'd you the execution logs.
I am also facing the same issue, with 3.1RC1 and later i found its an issue with the referencing.
when i try to click on the Already applied filer i get this error, and to solve it i have to delete this reference and recreate a new reference (apply Filter)
The issue you are facing is related to null pointer exception. Somewhere in UI, some object with null value is getting accessed. Could you please share the logs and workflow with us to debug the issue?
Thanks and Regards
I have imported the workflow. Opened the workflow in designer. Opened the existing fliters in all the "automatically searched" objects. but i didnt hit any "unexpected" exception. Could you please suggest which object is causing the issue in the workflow.
Thanks and Regards
I am able to reproduce the issue with the attached dar. Could you please mention the WFA version on which the workflow is creaeted? And also register the case with netapp support team with the bug id 933928.
Thanks and Regards
I have narrowed down the error popup being shown in the UI. Seems the content from 3.0 didnt get correctly upgraded to 3.1.
I tried to reproduce this by creating a similar workflow in 3.0 and upgrading to 3.1 , but i didnt hit the issue.
It would help me if you can you please share the 3.0 backup of the system if possible ?
I'm afraid that Schwab won't allow me to share this content that freely. They have fairly strict rules around their IP. The code mod suggested in the previous post is working for us, and we will likely leave it in place at least until the PS Toolkit is fixed, and possibly beyond.
I encountered the same issue.
It was with a custom command. The powershell cmdlet set-ncquota throws this error, yet successfully does what it should do.
We worked around it by using -EA silentlycontinue. Not really nice, but it worked.
I think this is a timeout problem with the current controller. The standard timeout is 60s. If you issue $global:CurrentNaController.TimeoutMsec=600000 the timeout is increased to 600s. Please try if the problem persists. In my case a command that throwed an error on a specific controller subsequently worked.