Finally fixed SharePoint error OWSTIMER.EXE (0x0F08) 0x1358 8kh7 High The user does not exist or is not unique – caused by workflow to email non-existent user

Note: This situation is on MOSS 2007 with Nintex Workflow (Enterprise) 2007; Nintex Reporting is also active – I mention this upfront since it annoys me when I read articles and realize at the end that the author is referring to an earlier or later version of the product! 😉

So this one really had me annoyed and was causing serious headaches as it was essentially buggering up document review and approval workflow automation in a fairly critical site. Hopefully by sharing my particular situation it’ll help someone else.

For several days, I had noticed that my SharePoint MOSS ULS logs had dozens hundreds of lines of error messages:

10/18/2012 16:06:42.34 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.40 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.53 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.59 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.65 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:41.78 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:41.84 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.92 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.85 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:42.98 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:43.04 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:43.17 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

10/18/2012 16:06:43.37 OWSTIMER.EXE (0x0F08) 0x1358 Windows SharePoint Services General 8kh7 High The user does not exist or is not unique.

OWSTIMER.EXE is the process used by the SharePoint Timer Service which handles essentially all timer jobs – which can be a lot of places to debug.

Now if you search for that message you’ll find several discussions in various forums – with several possible solutions, but many seemed to point to invalid user accounts being referenced by a workflow. I also suspected it may have had to do with one of the service accounts used by SharePoint or the various apps on the server.

However, if it was one of the primary service accounts used by SharePoint that was invalid (for example on the web applications) or expired, it would cause far more than just errors in the logs.

So I went back through my workflows, and discovered that there was an employee who recently retired referenced in email notifications towards the end of the workflow – a simple email sent to her and another colleague to advise them that action needed to be taken.

So I went through the workflows, which are created & managed graphically through the browser with Nintex Workflow, that referred to her. I removed her name from all the steps or workflows, and the message The user does not exist or is not unique stopped appearing in the logs. Yay for me, yay for the users.

For a while.

Suddenly, they started appearing again… I was stumped (again)…

Even worse, I had workflows that were ‘stuck’ at various places where there they had no business pausing 😉 …. no approval action waits, no pauses or logical operators inducing a wait state…

Until today, when I finally saw a single document still in a workflow stuck at precisely the point where the email notification was to be sent to that former employee.

That’s when it hit me; changing the workflow doesn’t affect workflows already in progress (part of the inherent design process to ensure that a workflow completes based on the business process & people in place at the moment when it was initiated)… so that one existing previous version of the workflow continued through it’s stages until it got to the notification step – and jammed trying to retrieve email contact info for the account that no longer existed. So I stopped the workflow on that one document (which had finished the approval stages anyhow) and then restarted the SharePoint Timer Service.

So what’s the lesson learned? As always, try and manage your user accounts (be it for workflow notifications or security) in groups, even if only a group with 2 users! That way, when a person leaves the organisation (or a specific responsibility) you simply remove them from a group and not from workflows that may be in many many places. The advantage is also that even if a pre-existing workflow is running, it will query the group membership… and not specific user accounts directly in the workflow.

 

My readers got here searching for: