Hello,
We have a demand workflow that uses a Request Review action at end of Stage 1 of the ept, to allow the Project Owner to explicitly control the stage exit to the next stage. The Request Review has one Reviewer defined and iit is the built-in workflow variable 'Project Owner'. This workflow tested successfully start to finish in the dev/test environment, but we have now deployed it to our production environment and it bombs out, and the workflow terminates, at this action step. We strongly suspect that the problem is a mis-configured PS 2010, or NW4PS, or both. We have wrestled through several configuration issues and were able to correct them, and thought we had all working healthy until we ran into this brain-teaser.
Because of the defense security restrictions, I cannot include the verbatim workflow and ULS log entries that describe what happens when it bombs, but here are some extracted snippets:
In the Nintex workflow logs, we get:
“Error in request review action. Object Reference not set to an instance of an object.”
In the corresponding ULS log, we get:
“Unable to get domain dns or forest DNS for domain SHAREPOINT.ErrorCode=1355”
“Unexpected : Nintex.Workflow.NWException:Could not get Directory Searcher from SharePoint.”
Here are some troubleshooting steps we've taken:
I edited the workflow, in an action well before the problematic action I added a 'write-out to workflow history' statement:"The project owner is: <Project Owner variable>."
In the problematic Request Review action, I changed the Reviewer of the action replacing the lone Reviewer of "Project Owner" to be my actual domain user id (and its important to note that during this design-time edit, the form was able to take my first name, last name, do an AD DirectorySearch, and come up with my AD domain id to populate the Reviewer field of the action. I then saved and published this workflow revision.
I created a new project that uses this workflow, checked it in, and then monitored the workflow progress to observe whether it would again blow up with my explicit AD user id vs. 'Project Owner'. It did NOT blow up, it continued successfully on with the next wf stage.
In checking the workflow history details of what occurred, I confirmed that the write-out to the history log showed 'Project Owner' indeed was populated, it held my "firstname lastname" in it. So what we know so far is, when an explicit AD user id is supplied as reviewer in the design of the workflow, at run-time the workflow does not have to issue any DirectorySearch since it already has the explicit user id, and hence it works fine. But when the 'Project Owner' wf var is defined to be the reviewer, at run-time the DirectorySearch that the action calls to resolve Project Owner, i.e. "firstname lastname" to an actual AD user id is what is blowing up and kills the workflow entirely. To repeat, this error did NOT ever occur in dev/test, only in production.
What I'm hoping someone can tell me is what components, dlls, or services of what applications (NW4PS, PS2010, or SP2010) would be involved with this DirectorySearch, and ultimately where should we focus our configuration checks and fixes.
Thanks,
George D
