Workflows don't run after installing SP1 on MOSS 2007

Question

Hi,

After implementing SP1 on MOSS 2007 I've encountered a problem with workflows that have been created in Sharepoint Designer. They don't start automatically. There are no error messages, they just fail to start. If the same workflow is run manually, it works OK. However, creating or changing items on lists does not run the workflow. Neither resaving nor recreating the workflows makes it any better. Please help!!!!!

Answer 1

 

we seem to have the same problem: automatic workflows created in SPD don't start, they don't even show up in the workflow history at all. and there are no errors anywhere on the server even with 'verbose' logging turned on. the problem seems to have started after deploying SP1 in our environments but I am still investigating this further.

 

and yes, manually starting the same workflow works without any problems. and automatic workflows created through the browser (i.e. the simple approval workflow) seem to work fine as well.

 

another post about the same problem: http://randomdust.com/blogs/ryan/archive/2007/12/14/issues-with-wss-sp1.aspx

 

anyone any ideas what could be the problem?

 

jeroen

 

Answer 2

ok, it seems that Designer workflows that start automatically only do not work when you are logged in (and adding or changing an item) using the Farm Admin account, it works fine for a normal user account.

 

I wonder if this was introduced by SP1, but at least I have never noticed this before and I am pretty sure that I have always tested such workflows with an administrative account. Anyway, shouldn't be a problem as long as it works for all other accounts.

 

still strange...

 

jeroen

 

 

 

Answer 3

Actually, this is a HUGE issue, and I'm hoping that someone from Microsoft might read this and escalate this.

 

We have an Internet facing site that allows anonymous users to request information. We used a user control to create an item in a list (using elevated permissions). The item was thus, created with the System Admin account. We then kicked off a workflow upon the creation of this item and routed it to the right person.

 

BUT NOW, THIS NO LONGER WORKS. Microsoft has severly limited the use of MOSS in an internet facing site, due to the fact that you cannot start anonymous workflows.

 

This has caused us huge pain...

 

FYI.

 

Answer 4

That shouldn't really be a problem.  Your code that utilizes run with elevated priviledges probably shouldn't run with admin rights (actually its site owner rights).  All you need is an anonymouse access account that has the rights that you need for the anonymous users, and impersonate the user in your code.  Try not to swat a fly with a hammer utilizing runwithelevatedprivildges....  There are plenty of sites showing you how to use impersonation to gain access to a site.  If you need further help with that...  My blog is http://sharepointblogs.com/chadclarkesmossblog.  I have a blog on how sharepoint handles security programmatically.  Feel free to comment with any questions.  But essentially you can still gain this functionality despite the new security enhancements provided in SP1.

 

Answer 5

We're seeing this with our server after it was updated to MOSS 2007 SP1. We created a workflow in SharePoint Designer 2007 that is associated with a document library.  Incoming E-mail is enabled for the document library.  When an email arrives, the workflow is supposed to automatically run.  Worked fine before SP1. Now, nothing happens.  No error, just nothing. It's worth mentioning that the workflow in question works just fine when manually started. What's going on?  What did Microsoft change in SP1?

Answer 6

I need to know what they changed as well. I am currently unable to deploy SP1 to production due to this issue.

 

We have a custom workflow that creates items in a different List and now any SPD workflows attached to that list will not run. It works just fine pre SP1.

 

I have even tied impersonation in the custom WorkFlow and it still does not work. Here is the impersonation code I've tried:

 

public void Process(SPListItem reportListItem)

{

  SPSite impersonatedSiteCollection = null;

  Guid currentWebID = reportListItem.Web.ID;

  SPUserToken userToken = reportListItem.Web.CurrentUser.UserToken;

 

  using (impersonatedSiteCollection = new SPSite(reportListItem.Web.Site.ID, userToken))

  {

    SPWeb impersonatedWeb = impersonatedSiteCollection.AllWebs[currentWebID];

 

    SPListItem notification = impersonatedWeb .Lists["Notification Log"].Items.Add();

    notification[notification.Fields["NotificationType"].Id] = notificationType;

    notification.Update(); // trigger notification workflow.

  }

}

Answer 7

Impersonation does work, but I had a bug in my code I posted. The following line returns the System User not the current user:

reportListItem.Web.CurrentUser.UserToken;

 

In order to impersonate I need the user that created the list item. Do do this i had to add this code:

string modfiedBy = reportListItem[reportListItem.Fields["Modified By"].Id].ToString();

string loginName = modfiedBy.Substring(modfiedBy.LastIndexOf("#") + 1);

SPUser user = reportListItem.Web.AllUsers[loginName];

SPUserToken userToken = user.UserToken;

 

Here is the code that works:

 

public void Process(SPListItem reportListItem)

{

try

{

SPSite impersonatedSiteCollection = null;

 

string modfiedBy = reportListItem[reportListItem.Fields["Modified By"].Id].ToString();

string loginName = modfiedBy.Substring(modfiedBy.LastIndexOf("#") + 1);

SPUser user = reportListItem.Web.AllUsers[loginName];

SPUserToken userToken = user.UserToken;

 

using (impersonatedSiteCollection = new SPSite(reportListItem.Web.Site.ID, userToken))

{

    SPWeb impersonatedWeb = impersonatedSiteCollection.AllWebs[currentWebID];

 

    SPListItem notification = impersonatedWeb.Lists["Notification Log"].Items.Add();

    notification[notification.Fields["NotificationType"].Id] = notificationType;

    notification.Update(); // trigger notification workflow.

  }

}

Answer 8

I'm having the same issue. Since the new list items are being added via email, it's always the system account that creates them.

 

How do you setup a mail-enabled list to creates items sent via email with a different account?

 

Answer 9

Does anyone know if only workflows created in sharepoint designer have this issue? I wonder if a workflow created in visual studio will start on new item?

Answer 10

After alot of digging around I think I may have found the problem  - There was a corruption of the auto-alert functionality of the standard workflow task list .

 

Have you tried this as a workaround :-

 

1.Go to Site Actions -> View All Site Content -> Create tasks - name the list as something like New <list> workflow tasks and do not show on Quicklaunch, but select YES to "Send Email when ownership is assigned" click OK

 

2.Go to Site Actions -> Site Settings -> Modify All Site Settings -> Site libraries and list

(Repeat this bit for all lists that have been using the standard approval workflow)

customise <list> -> Workflow settings -> Remove existing workflow -> Select "Remove" then OK

 

3.Click "Add a Workflow" use the same type as the removed workflow, type the workflow name (Like <list> approval workflow) and most importantly Select the new Task List that you created in Step No 1 as the task list to use . (The rest of the options are up to you)

 

It worked for me after doing this workaround.

 

Nigel

Answer 11

This is a side affect of SP1 for workflows created by SPD - as they will no longer run when you are logged in as the System Account.

 

Here's the official workaround...

 

http://kbalertz.com/947284/declarative-workflow-start-automatically-after-install-Windows-SharePoint-Services-Service.aspx

 

- Ben

Answer 12

Thanks for the info.. but maybe I"m missing something.

 

I'd like to be able to start a workflow either by sending an email to a library/list (thus, creating and item) or by using the object model to create an item in a list using elevated permissions.

 

So.. when I create those items, they are created using the system account, right? So even if I change the domain account in the app pool... I still have the same problem, right? I can change the account, but then the new item is created using that new account and it is STILL the system account, so the item will not kick off the workflow?

 

Am I missing something (I really hope I am..)

 

Thx

Answer 13

This is one of those issues that really needs attention, after placing a support call and being handed off to the Office support group the official response is to set the workflow to be started manually. Absolutely unacceptable as a major piece of functionality is to be able to add items to oh say a calendar list via your outlook client and since the sytem uses the timer service for mail delivery and if there should be a problem with said uber reliable timer service and the message does not get delivered, the user will have no way of knowing since no NDR is generated. Hence the need for a workflow that is kicked off when an email calendar event is added to the list, said workflow would start a process of emailing the user an acknowledgement of receipt. Just my 2 cents worth. 

Answer 14

Here is the official response from Microsoft support, I hope that anyone reading this will take the time to let Microsoft know that this is unacceptable.

 

Thanks for your response. This is not my favorite response to give. We've discussed this with our product team because other customers have brought this to our attention and this is the response we got from them when we requested this behavior to be reverted to it's previous state. The only way to make this work is to restore your databases to a point prior to the service pack being installed and uninstall and reinstall the bits for SharePoint so the DLLs are not at the SP1 level.

There might be ways of creating a custom solution using the SharePoint SDK but that will involve creating your own custom solution in Visual Studio.

Answer 15

Last I had heard from Microsoft this was considered a bug (Bug No. office12: 807303). 

 

We have not heard otherwise until this post. If Microsoft are not going to remedy this then they should inform the poor developers who are losing customers who built their solutions around email submission workflows.

 

Is there an official way to let Microsoft know that this is unacceptible?

 

Answer 16

The response I got was from the SharePoint Designer team, when I opened the ticket it was with the server group and was immediately passed to the Designer group. The person I spoke with in the designer group is the one that sent me the response I posted earlier. I made it very clear to him that this akin to taking your brand new car in for the first service and when you pick it up you find they have removed the gas pedal because it was a safety issue.

Answer 17

Hi,

 

We are facing the same problem.

 

We implemented the workarround as suggested in the the article at "http://kbalertz.com/947284/declarative-workflow-start-automatically-after-install-Windows-SharePoint-Services-Service.aspx". It did solve this problem on two of our servers but one server is still having the same problem even after implementing the workaround.

 

Any advice or guidelines to proceed with the solution will be highly appreciated.

 

Thanks & Regards

 

 

Answer 18

 

hi

 

WE are not able to implement the step as defines in the above link

it gets reset automatically to a defaul setting

 

is there any other workaround?

 

 

~Mehul

Answer 19

Chad Clarke 323 wrote:

That shouldn't really be a problem.

 

Well it is a problem... a big problem. This stuff worked and now it doesn't. You create a workflow in SPD like this:

(a small piece of a larger WF that is supposed to start with a new item)

 

If __ equals ___

and __ equal __

copy item in List A to List B

then delete item in List A

 

Set to run when an item is created... and now it doesn't work to route important documents after SP1 is fielded! They work only when manually initiated now... and that is not good enough for knuckle draggers who want to minimize effort with computers. (alot of this frustration stems from the fact that the majority of applications I have for SPD (which is the only tool available at this time) center around automating processes which makes my efforts dead in the water.)

 

(Revised)

Microsoft needs to address the issue with an actual solution after actually looking at the problem. People who think they know (and arbitrarily give solutions) should just hold their peace until they actually try it. Now let me qualify that statement to say that people who are trying to help with a suggested (they don't think they know) solution are not the problem... it's people who think they know. And when you’re talking to a SPD user building workflows... we don't code! WYSIWYG! We rely on coders to make an interface that accomplishes what we want... and in this... Microsoft has crippled an extremely important function of workflows... initiating upon creation of an item.

 

 

 

Answer 20

SFMOSS:

 

You're frustrated, we get it, and,I believe, rightly so.  However, please realize that this is a community forum - none of the people who answer questions here are compensated for their time/effort.  So by asking people to not answer if they aren't 100% sure of their answer is going to reduce the value of this forum immensely.  What you're looking for there is free consulting.

 

Personally, I spend a few hours/week on here trying to help out - but I'm not here to solve your problem for you.  I'm here to help you solve it by providing answers to very specific questions.  Trust me, the questions that are essentially "please post the code that solves my business problem for me so I don't have to do it" get ignored.  Rarely if ever does anyone on the forum respond with a "I've tested this in every conceivable scenario and guarantee that it will solve your problem" type answer.  The vast majority of the answers are suggestions - and quite often, they do solve the problem.

 

To your point of SPD users not coding, this is not always true.  Many SPD users do code - there is just a specific reason they are using SPD in this case.  Along the same lines, SPD is a tool, but it is not the only tool.  If it does not do what you want/need then you need to look at other tools - Visual Studio does come to mind - and just because you can't make use of it doesn't mean that it is not a valid tool.

 

Last I looked, Microsoft was a business interested in making money and satisfying its customers.  Trust me, they do not remove functionality or cripple feeatures on a whim.  The fact that they did so  - and reiterated that it was intentional - means that there was a bigger problem that was solved and this functionality going away was an unfortunate side effect.

 

Finally, your sample process above is probably not really a good candidate for a workflow anyway.  It would likely be better handled via an Event Receiver on the List.  The tool for building Event Receivers is Visual Studio, not SPD.

 

I'm not looking to start a flame war, just explain a few things about SPD, WF and forum etiquette.

 

Just my $.02

 

-Dave

 

PS: I do agree with you that this is a problem, but trashing the people who are trying to help you won't get you anywhere.

 

 

Answer 21

My frustration was solely from the tone of the answers provided by some, and the "official response" of Microsoft regarding this issue (although in one case their response was prefaced by regret regarding the nature of the response by the respondent, "This is not my favorite response to give."). The particular individual I quoted in my previous post was dismissive of the problem and arbitrary in his solution and assumptions of the problem.

 

Your sharing of your personal time (and other pro's like you) to help people out with suggested solutions to general or specific problems was never under fire. My post was based on frustration regarding the treatment of this problem and the defense of Microsoft's position which amounts to, "too bad it still works manually, program your own fix". You would think that the two solutions/reasons regarding this issue that have been fielded by experts, such as yourself, would be made official suggestions by the company given with credit where credit is due. And from the long history of responses I have seen Microsoft field regarding bugs that affect what might be a minority of users... You can't please everyone and who else can you turn to anyway... Linux? "Works best in your mom's basement" (Got that from a hilarious video from TrueNuff.com spoofing PC vs. MAC commercials... if you haven't seen them, you need to: http://tv.truenuff.com/mac/)

 

You are one of those individuals in fact... Since your sites suggestion of security trimming also seemed a likely cause of this problem that I came across. And of course the KBAlertz.com fix RE: A declarative workflow does not start automatically after you install Windows SharePoint Services 3.0 Service Pack 1 http://kbalertz.com/947284/declarative-workflow-start-automatically-after-install-Windows-SharePoint-Services-Service.aspx

 

And finally, that was only a single branch of several of one step of my SPD (which is the extent of what is available to me) workflow given as an example . I am using this in a military setting and can't give many more details... which would look silly with a bunch of blanks or A's and B's. Your recent post regarding the Ted Pattison Group and SharePoint training might land you a shot at some military funds so don't treat me too harshly... lol... Our IT guys really need the help.

 

Yes, I checked out visual studio... unfortunately I am the only one in my unit that desires to implement true information management rather than just setting up hardware and saying "put your files here". So the funds will be slow in coming, especially since this is technically out of my lane at this time. I just get frustrated with coders in other SPD specific forums (of which I realize this isn't) that answer SPD problems with VB solutions that non-coders can't use. Yes, we non-coders get it... 3rd party solutions not coded by yourselves should be banned and superusers shot (I am just being poking fun with those statements in case text fails to convey it).

 

So in my post, as I said, "People who think they know should just hold their peace until they actually try it. Now let me qualify that statement to say that people who are trying to help with a suggested (they don't think they know) solutions are not the problem...” To be fair and honest I wish I had not said "I hate it when you look for an answer and all you get are opinions and suggestions.", which most likely set you off in particular since as you said most are put out by well meaning non-egotistical people donating valuable time and expertise to help the user community.

 

So thanks for your $.02, I will invest it for a handsome return

 

Best regards and V/R,

 

SFMOSS (or more accurately SFSPS 3.0... they didn't go for MOSS 2007 for some reason

 

Answer 22

"Last I looked, Microsoft was a business interested in making money and satisfying its customers.  Trust me, they do not remove functionality or cripple feeatures on a whim.  The fact that they did so  - and reiterated that it was intentional - means that there was a bigger problem that was solved and this functionality going away was an unfortunate side effect."

 

I'm glad this thread is still intact because the statement above is patently untrue. When SP1 was part of an 'automatic' update it effectively killed three of our sites. After many hours of troubleshooting we finally gave in and put in a support request. No one there had any idea what the issue was and we had to build two comparison sites to prove our point. It was finally determined after two weeks that this was indeed a bug with vague assurances that it would be fixed. Still hasn't been fixed. I would assert that this was not intentional but an accidental side effect that was not anticipated because one side wasn't talking to the other.

 

I share SFMOSS's frustration. For certain developers this is major. We have now lost customers who were taking advantage of an email submission workflow- now broken. To my knowledge the documentation has not been updated to reflect that this functionaity is no longer supported. Pity the poor fool who tries to implement it in SPD.

 

I guess the smugness and Kool-Aid drinking is particularly griping because it trivializes the issue and sends a 'get over it' message to folks who are trying to implement sites that they believe are of real value. It takes a long time to get user buy-in for these sites. People do not like to be managed by systems and resist the imposition of a content management solution. Automation helps system adoption because you can make the case that they will do less not more to manage tasks. When it breaks they lose faith in the systems and revert to prior behavior and SharePoint gets the boot.

 

My point is that SharePoint is a hard sell. If Microsoft wants wide adoption, the features should work as advertised and features that are removed should be itemized clearly and unabiguously. This was not done with SP1.

 

Let's hope that it is of sufficent importance that it gets fixed ot at least there is a reasonable workaround.

 

Answer 23

 

Hi

 

Where are you now ?

 

We have the same issue with SPD workflow.

 

We juste want this : When an emain arrive on a library, do something.

Before SP1 all worked fine.

 

We are not SPD or VisualSutdio developpers, we trie the http://support.microsoft.com/kb/947284  solution but it still not work.

 

What can we do ??

 

Regards,

 

Philippe

Answer 24

This is cool!

After more than a year, my company finally starts with Sharepoint and with my first productive application, Microsoft shoots me in the back for updating my server.

Many thanks!

Answer 25

We logged a priority Premier Support call over this as soon as it appeared and have liaised with the product team over suggested paths to fix it. Currently it is under consideration for a hotfix - note that this isn't a guarantee of one, but as of 23 Apr 2008, the hotfix team were looking into it.

 

Answer 26

I don't have much to add, apart from adding another user to the list of affected.

 

Our problem is documents created by incoming e-mail do not trigger a workflow set to run on a document being created.

 

If we create a document using the web interface, all works as expected.  If we manually run the workflow, all is fine.

 

It's just the incoming e-mail triggering that doesn't work.

 

I hope a hotfix for this problem is forthcoming, it would make my life a lot less troubled.

 

Guy

Answer 27

Are there any new developments regarding this problem?  I'm dead in the water here.

Answer 28

Anyone have an update on this?

 

Answer 29

 

I just ran into this today as well.  Thought I was doing myself a big favor by upgrading to Servcie Pack 1, but alas I did myself in.  We are able to use a three part workflow to solve my problem...but this really is shameful of Microsoft...how many hours must I bang my head against my computer to find out THEY BROKE IT!  I hate second guessing myself....a few days wasted and research down the drain...tried to reprogram and use their KB fix...useless.  Now I have to explain to my boss how a "free" solution like WSS isn't really free.....BIG TIME WASTER!!!  Thanks Microsoft, this is supposed to be your flagship product!

Answer 30

 

Please provide a hot fix ASAP!  Now I look stupid for suggesting to use Windows SharePoint as a solution!  What a disaster!  I spend weeks planning for this upgrade and this is my reward????  Unbelievable...

Answer 31

Does anyone have a fix for this yet? I have spent 8 hours on this already.

An event receiver won't work for me because I need to send an outgoing email and I am getting an error 5.7.1 when trying to send outgoing email programmatically.

This is such a simple thing. I've tried just about everything I can find online. I can't believe it's not working.

Answer 32

I have heard rumors that there is an unsupported hotfix (not confirmed), that does restore the email capability but in the long tradition of so many other hotfixes breaks a few other things.

 

Answer 33

 

Please refer to this article

 

http://www.codeproject.com/KB/sharepoint/SharepointWorkflow.aspx

 

Answer 34

Sorry- this doesn't work.

This has been posted as a solution but in most cases it does not work when a user sends an email to a library to trigger a workflow.

It does work if there is an automated move from one library to the other or similar activity.

This has been posted before.

clindsay

 

Answer 35

MSFT just released an "infrastructure update" that addresses this issue (and many more): http://blogs.msdn.com/sharepoint/archive/2008/07/15/announcing-availability-of-infrastructure-updates.aspx

 

If you follow the links, you get to this: http://support.microsoft.com/kb/953749/

 

Here's the key point as far as this thread is concerned:

 

List of issues that are fixed

This update fixes the following issues:

•	953289 (http://support.microsoft.com/kb/953289/) A declarative workflow that is configured to start automatically when e-mail enabled items are created does not start automatically after you install Windows SharePoint Services 3.0 Service Pack 1

 

This specifically addresses email triggering workflow.  It does not address other scenarios with the system admin account starting workflow automatically.

 

I have not tested it.  If you're having this problem with email and you install this, please let us all know here how it works out!

 

 

Answer 36

Has anyone had any success with this new infrastructure update?

Answer 37

YAHOO!!

Finally.. after months of waiting, a solution! I have successfully applied the infrastructure update to a VM running WSS 3 with SP1.

My incoming e-mails now fire a SPD created workflow.

Don't forget to run the following command after setup.

stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true

Thanks to all who kept this thread alive!

Answer 38

 

Knowing it now works, as anyone tried this on a farm?

Answer 39

On standalone the patch appears to work on text files and XML files but not on PDF or Word files. Don't know why.

Seems to be spotty at best.

I may not be supporting non text attachments or ther may be a MIME setting somewhere.

Any ideas appreciated.

-clindsay

 

Answer 40

Everything seems to work on a single server, and so far so good on a Farm.

Testing of PDF documents were our first tests and they go through just fine.

Answer 41

We simply coded our Webpart that creates the new ListItem to start the workflow right after creating the new list item.  This should solve most problems people are having, simply create custom webparts for your forms, and have the webpart start the workflow after creating the item.

Link on how to do that: https://blogs.pointbridge.com/Blogs/herzog_daniel/Pages/Post.aspx?_ID=3

---

Matt

Answer 42

Apparently you have not been reading the earlier posts in this thread, if you were you understand that the issue is not how to do it with any kind of custom code but just to be able to do what was originally delivered with the product and then broken with a Service Pack. Hope that makes it all clear for you.

Answer 43

 

This from http://support.microsoft.com/kb/951695

"Installing the Windows SharePoint Services Infrastructure Update that contains the fix for e-mail-triggered workflows was determined not to resolve this problem for document libraries. The fix does correct the e-mail-triggered workflows behavior in generic lists. Microsoft is aware of this issue and is developing a solution. "

We observed behavior where some workflows fired on attachments emailed to document libraries some did not. Appears that the initial ones(lower ID) are more likely to fail than later. There also may be a relationship with dumping attachments in folders.

clindsay

Answer 44

I have just run into this issue.

I have a custom workflow activity that that copies an image to a different site. When the image arrives at the new site it needs to start a new workflow to send out an email notification - because of the permission on the second site I cannot have the email initiated from the first workflow.

I have now spent an INORDINATE amount of time trying to get the custom workflow activity to copy the image as anything other than System Account. I have tried changing the application pool account, and I have tried the impersonation solution (from page 1). It doesn't seem to matter what I do the item is always copied with modified by = System Account, so the second workflow does not start with the SP1 'fix'.

I still have no solution at this point.

Answer 45

fosterl - simply add the code to start the workflow you need in your first custom workflow activity.  You can find the code for Starting Another Workflow at: http://www.codeplex.com/SPDActivities/Wiki/View.aspx?title=Start%20Another%20Workflow&referringTitle=Home

Thats the only solution we found to work :|

---

Matt

Answer 46

Hmm, I can't add that code to the same activity since it's used elsewhere. But I guess I could make another activity that starts the workflow on the second site and then chain them together in SPD. I can almost use the one you suggest as is except it's only for workflows within the site.

Anyway - a lot of effort to go to for something that was due yesterday - I ended up applying a band aid by making distribution groups in exchange and sending email to those from the first workflow.

Answer 47

Does this also solves the same problem on a MOSS 2007 (SP1) server?

Answer 48

hi i have the same problem but just when i create the item through email any solution ?

 

---

Microsoft Lover

Answer 49

Currently my findings are that aprox 50% of all items that are coming inbound are kicking off SPD workflows. 

Does anyone else have this issue?  Is there a work around that anyone knows about?

I have changed my app pool's user account, and also Installed: http://www.microsoft.com/downloads/details.aspx?FamilyId=3A74E566-CB4A-4DB9-851C-E3FBBE5E6D6E&displaylang=en
Ran: stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true

Please assist!

Thanks!

---

Bill

Answer 50

 Bill Daugherty II _ I feel your pain, I have been struggling with this for a couple of days. After I installed the cummulative update:

http://support.microsoft.com/?kbid=960011

it appeared to have been rectified, however, its tempermental, sometimes it works sometimes it doesn't

I've got the following log snippet if it helps:

03/18/2009 15:58:39.61  OWSTIMER.EXE (0x0B60)                    0x156C Windows SharePoint Services    General                        8kh7 High     The file VoiceTranscripts/bv-inn-2008-1486-20090316-00474-00597.doc has been modified by DDD\devguy01 on 18 Mar 2009 15:58:39 +0900. 
03/18/2009 15:58:39.61  OWSTIMER.EXE (0x0B60)                    0x156C Windows SharePoint Services    General                        8e2r Medium   Possible mismatch between the reported error with code = 0x81070901 and message: "The file VoiceTranscripts/bv-inn-2008-1486-20090316-00474-00597.doc has been modified by DDD\devguy01 on 18 Mar 2009 15:58:39 +0900." and the returned error with code 0x81020037.

ideas please someone!!

Answer 51

Zero123456,  I just wanted to take a minute to let you know that I was able to resolve the problem... I did it though in several steps.

First, I installed: http://www.microsoft.com/downloads/details.aspx?FamilyId=3A74E566-CB4A-4DB9-851C-E3FBBE5E6D6E&displaylang=en
Second, I ran: stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true

And it all semed to work fine.

However, you might want to try the Feb CU first, then run the STSADM command above..

Let me know please if this also worked for you.

Bill.

---

Bill

Answer 52

Thansk 4 ur response Bill

It appears I have solved the issue. The workflow did not work when triggered automatically by email attachment because:

The workflow attempts to update the metadata of the attachment at the start of the workflow. When triggered automatically, the attachment has not finished saving into the document library before the workflow is triggered, therefore updating the metadata caused it to fall over.

The fact that it worked manually drove me nuts. Now I know when the workflow is triggered manually on the attachment, the workflow works because the attachment is already saved, therfore preventing any fall over when updating the metadata. doh!

thanks!

Answer 53

Thanks Bill.

Your solution fixed our problems with SP Designer workflows perfectly.

Johnnie

Answer 54

This morning I have had the same issue after that installed MOSS 2007 SP2!!!!

Now I'll try to run stsadm and hope that SharePoint God save my head :)

---

Fabio Alivernini