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.
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?
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
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.
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.
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.