none
Email workflow not working even though it says it's "completed" RRS feed

  • Question

  • I have a simple email worflow setup so that if field1 is equal to X, then email Y.

     

    The workflow is setup to be manually started from an item, whenever a new item is added, and whenever an item is changed. The workflow say's it's completed but I never get the email.

     I checked the SMTP server and it was stopped, I started it and still no luck getting it to work.

     I checked the "To: email address and I put it in there two ways: domain\myaccount and myaccount@company.com

     Still can't get it to work. Any ideas?

    I have a simple email worflow setup so that if field1 is equal to X, then email Y.

     

    The workflow is setup to be manually started from an item, whenever a new item is added, and whenever an item is changed. The workflow say's it's completed but I never get the email.

     I checked the SMTP server and it was stopped, I started it and still no luck getting it to work.

     I checked the "To: email address and I put it in there two ways: domain\myaccount and myaccount@company.com

     Still can't get it to work. Any ideas?

     

    Edited to Add: Email alerts aren't working either. I'm working from home using VPN, maybe this is why?

    • Moved by Mike Walsh FIN Thursday, July 1, 2010 2:50 AM workflow questions go to the workflow forum (From:SharePoint - Setup, Upgrade, Administration and Operation (pre-SharePoint 2010))
    Wednesday, June 30, 2010 9:12 PM

All replies

  • Could be the VPN, Were you having any issues with alerts or other mail relateds between SharePoint and Exchange when you are not remote or has this always been an issue?


    Tony Parker, MSCE . MCTP. MCITP "Anything worth doing, is worth doing right"
    Thursday, July 1, 2010 2:40 AM
  • It only seems recently it's been an issue. I'm having the same issue today from the office so it's not the VPN. The last time I know it worked fine was before service account changes, but the SMTP service for this installation runs as a local account and I didn't touch it.

    I wonder if it has anything to do with my service account changes but I have no idea how it would since the SMTP service for email runs as a local account rather than a domain account...

     

    Thursday, July 1, 2010 8:04 PM
  • I am getting the following error in my event viewer/application log" Event ID 5586 as well as Event ID 27745

    5586

    http://technet.microsoft.com/en-us/library/cc561042(office.12).aspx

    27745

    http://www.eggheadcafe.com/software/aspnet/30576497/error-event-id-27745.aspx

     It seems as though SharePoint cannot access the config database, so maybe this is what the problem is? I did recently change service account passwords. I did it all through the Central Administration site. I got it to work seemingly fine without running the STSADM commands so I didn't want to risk screwing it up since it was working by running STSADM commands that may screw it up.

    I went into the SQL Server Management Studio, but don't see anything unusual in the database owner settings in the security node for the configuration database. Seems to me that sharepoint can't access the configuration database. What's strange is the db_owner for the config database is also listed in the content databases yet the system doesn't appear to have any issues access the content databases. Users are able to submit new data to the database through SharePoint and retrieve it no problem.

    All of the content databases also just lis dbo in the db_owner properties. Some of the other misc. databases have domain accounts listed in addition to the dbo that's listed. It's really weird.

    Thursday, July 1, 2010 8:48 PM
  • Could it be the Timer Service? I did not restart the timer service and have some jobs stuck in the Timer Jobs Definitions in SharePoint Central Administration for Application Pool Credential Deployment.

    Since I just changed most of the accounts through central administration rather that through stsadm commands or on the back end services and just reset IIS, I did not reboot the web server. There was no way to change the Timer Service account through central administration so I had to do that on the backend. I don't think I restarted it after. It should still technically work even though I changed the password shouldn't it? Until I try to get it to reauthenticate by restarting it shouldn't it still run under the old credentials?

    Can anyone help me with this?

    Thursday, July 1, 2010 9:23 PM
  • Hi techieplaya,

     

    From your post. You changed the service account passwords recently. I suggest that you follow the following article do it again. Then check the effect.

     

    How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0

    http://support.microsoft.com/kb/934838

     


    Regards, Rock Wang Microsoft Online Community Support
    Friday, July 2, 2010 6:53 AM
  • I would like to explore other possibilities before I do that, thanks though. I wanted to note that I am able to change web application configuration settings and they seem to stick. Aren't these stored in the configuration database? Seems to me it is able to write to it...

    Also, I went to the mailroot folder and in the queue folder therein are all the emails that should be sent but arent.....Maybe this will help someone point me in the right direction.

    Friday, July 2, 2010 4:02 PM
  • It seems to be related to Windows SharePoint Timer Service from what I'm reading on other forums and experiencing.

    I have application credential deployments stuck in timer job definitions and emails/alerts are not working.

    Reading the description of the service in server manager, it appears as though this is the cause of both problems. This makes sense as I changed this service on the backend in server manager rather than through central administration. Windows Sharepoint Services Timer is started on all servers so I'm not sure what's going on. I didn't reboot the servers when I changed credentials I just IISRESET /noforce so it's possible that I didn't restart this service but if I didn't then it should still be authenticated in with the old password.

    Or maybe the config database has the old password for this service and is overiding it? I don't know, can anyone help with this?

    Friday, July 2, 2010 4:38 PM