This has to be the most annoying issue i’ve come across.
Setup:
- Sharepoint 2007 version 12.0.6425.100 (SP2)
- AD accounts used within SharePoint groups for permissions – i.e. no direct permissions on the site.
- Workflows go straight into the “Stopped” state. No workflow history logged, and appears to be intermittent – works one day, but not the next. Error logs don’t really provide any useful information.
- Co-incidentally, alerts may appear to be intermittently received
- Sometimes, when a workflow email is sent to a group SOME may receive the email and not others.
- You’ve tried to change the permission level of the SharePoint groups. This sometimes works, and the workflows appear to start working again.
- You’ve changed SharePoint group membership to be viewed by ALL, not just group members.
Replication
1) You need 2 users – User A and user B.
2) User B needs an alert set on the site.
3) NULL out the following for User B in the WSS_Content database
BEGIN TRANSACTION
UPDATE WSS_Content.dbo.UserInfo
SET tp_ExternalTokenLastUpdated = NULL,
tp_ExternalToken = NULL
WHERE tp_Login=’LOGIN NAME’
AND tp_ID = ID
COMMIT
4) User A makes the alert fire (e.g. add an item to the list)
5) Wait for the timer job to fire, use the SQL to check the values for user A in the database. This should be :
tp_ExternalToken : Length 60, starts with 0x3C
This indicates failure.
6) User B should now get stopped workflows, and not receive alerts.
7) Re null out the values (as step 3), and as User B, visit the site. Wait for the timer to fire – and check the values in the table. This should have tp_ExternalToken of length > 60, and NOT start with 0x3C. Workflows should now work for User B AND this user will receive alerts.
Cumulative Updates?
There appears to be a fix in the October 2009 cumulative update for WSS3.0… however, this doesn’t appear to have fixed the scenario above.
This problem is still ongoing, but at least we know what’s happening.
Update
We have discovered that the account the Windows SharePoint Services Timer account needs to be in the built in AD group “Windows Authorization Access Group”.
All tests since have been successful.
See also http://support.microsoft.com/kb/331951
Image may be NSFW.
Clik here to view.
