none
Task assignment email notifications not sending only when certain users assign tasks RRS feed

  • Question

  • I'm having a weird issue with SharePoint 2010. When certain users assign tasks, the email notification does not send, as far as I can tell. SMTP settings are correct, and task assignment emails are sending for most users. Also, item-level permissions allow all users to read and edit all items.

    The only difference between the users being affected by this and all other users is that the users for which emails do not send were all created within the last 2 years. Prior to these users being created, we were running on an on-prem Exchange server. We have since moved to Office 365 for email, with a on-prem Exchange relay server. SMTP settings were all updated properly. Additionally, if any of these "new" users assigns a task to another "new" user, then the emails sends just fine. Email domains/addresses/aliases did not change during the migration.

    Consider this scenario:

    • Users A and B were created prior to the Office 365 migration, and Users C and D were created after.
    • If either User A or User B assigns a task to anyone, the notification email is sent to the assignee.
    • If User C assigns a task to User D, the email is sent.
    • If User C assigns a task to User A (or User B), the email does NOT send.
    • If User A assigns a task to User C, the email sends. If User C reassigns this same task to User B, the email does NOT send.

    Any help would be greatly appreciated.

    Thursday, September 5, 2019 6:47 PM

All replies

  • If User C assigns a task to User A (or User B), the email does NOT send.

    - Does the user C has a AD object or its created directly on the cloud ? 

    - In on-prem exchange powershell , do you see any results  when you run the following command,

    Get-RemoteMailbox UserA

    Get-RemoteMailbox UserC



    S_K_P

    Thursday, September 5, 2019 7:25 PM
  • All were created in AD and synced to the cloud (via AAD Connect).

    Get-RemoteMailbox yields remote mailbox info for both users. As far as I can tell, remote mailboxes and remote routing addresses have been set up correctly.

    While troubleshooting, I've been using Message Trace in 365 to see if/when emails are sent from our SharePoint's email address. When User C or D assigns a task, Message Trace shows no record of an email coming into our environment, so I assume that SharePoint isn't even sending anything, but I could be wrong.

    Thursday, September 5, 2019 7:35 PM
  • When the task is assigned by UserC to UserA does the user actually gets the task , right ? 

    Only email is not getting  generated, correct ? 


    S_K_P

    Thursday, September 5, 2019 10:39 PM
  • Hi Adam2727, 

    Restarted the SharePoint Timer Service on all Farm servers and compare the results.

    Best Regards

    Lisa Chen 


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    SharePoint Server 2019 has been released, you can click here to download it.
    Click here to learn new features. Visit the dedicated forum to share, explore and talk to experts about SharePoint Server 2019.

    Friday, September 6, 2019 7:53 AM
    Moderator
  • That is correct. When the user logs into SharePoint they can see the task and see that it is assigned to them. Only the notification email is not being generated.
    Tuesday, September 10, 2019 12:31 PM
  • I have restarted this service, but he result is the same.

    Adam

    Tuesday, September 10, 2019 12:32 PM
  • Hi Adam2727, 

    If User D assigns a task to User A (or User B), will the email be send?

    Best Regards, 

    Lisa Chen 



    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    SharePoint Server 2019 has been released, you can click here to download it.
    Click here to learn new features. Visit the dedicated forum to share, explore and talk to experts about SharePoint Server 2019.


    Friday, September 13, 2019 8:54 AM
    Moderator
  • Hi Lisa,

    No, that email is not sent. If User D assigns to User C, then the email is sent.

    Adam

    Friday, September 13, 2019 1:00 PM
  • Check permissions for all users.  

    1. Go: Site actions > Site Settings > Users and Permissions > Site Permissions
    2. Click on the Check Permissions button
    3. Enter a user, and then copy down the result
    4. Repeat for each of the other users involved
    5. Compare the results

    Check list permissions

    • are they unique or inherited from the web?
    Saturday, September 14, 2019 4:28 PM
  • All 4 users have the same permissions, as they are a part of the same group. I double checked to make sure.

    The "Tasks" list has unique permissions, but I imagine this is because there is one user (not associated with this issue) that has been given permissions to this list individually instead of being added to a group. Not sure why, as this system predates me. The group that all of these users live in has the same permissions for this list (Contribute) as it has for the site.

    Monday, September 16, 2019 2:53 PM
  • Next (simple) line of troubleshooting:

    Trigger the workflow for someone who is not getting the notification but should.  Note down the time when you do.  Then review the ULS logs around that time - for example, search by the name of the workflow or the user who should be receiving the notification, etc.  Usually, I have the workflow engine running on the same server hosting CA, so I start checking that one first, and then check the ULS logs on the other servers in case it shows up there.  If nothing shows up, change ULS logging to verbose and try again.

    More complex troubleshooting:

    1. Create a simple workflow that sends out a notification to that same user.  Write the workflow with log statements before and after so that you can check the workflow history.  This verifies that the user can actually get notifications from workflows.
    2. If that works, return to the problematic workflow and add logging statements after every action to see where the workflow hiccups.

    Tweak and test.  Tweak and test.

    Other troubleshooting tests:

    Create a new list and leave the permissions inherited.  Add that workflow to this list and test.

    Monday, September 16, 2019 10:50 PM