SharePoint 2013 Incoming E-Mail Feature Troubles Configuring SMTP Services
What is the SharePoint incoming e-mail feature?
The incoming e-mail feature in SharePoint enables sites to receive and store e-mail messages and attachments within SharePoint lists and libraries. Making it possible for teams to store the e-mail that they send to other team members without needing to go to the SharePoint site and upload the content that was sent in e-mail. What makes this possible is the ability for lists and libraries to be assigned a unique e-mail address.
Before configuring incoming e-mail, you must perform the following tasks (depending on the type of implementation you choose)
Incoming e-mail service timer job
Back in SharePoint 2010, the Incoming e-mail service timer job had an SPJobLockType of None, which meant that the job ran on all servers in the farm, as long as the Incoming E-mail service was deployed.
TechNet Article: SharePoint Administration SPJobLock Types Defined
When SharePoint 2013 was released that SPJobLockType had changed to Job, which meant it could only run on a single member server in the farm. This presented a problem for SharePoint administrators upgrading from SharePoint 2010 that intended to use round-robin MX records. Administrators had to disable the Incoming E-mail service on all SharePoint 2013 servers except the one designated by the MX record. By doing this it prevented the Incoming e-mail service timer job from running on a server that didn’t actually contain e-mail.
SharePoint 2013 Incoming e-mail service changed!
In December of 2013 Microsoft released a cumulative update for SharePoint 2013 Foundations that included a change to the Incoming E-mail service timer job. Essentially it set the SPJobLockType back to None allowing administrators to take advantage of the multi-server Incoming E-mail service deployment option.
But the December 2013 CU didn’t help?
In some cases when an administrator applied the December 2013 CU they did not see the expected change in the SPJobLockType. In these cases the problem occurred because the Internal E-mail service was already in place prior to the application of the December 2013 CU. So the SPJobLockType remained the same (in Job state). What the administrators in this case needed to do was to remove the existing Internal E-mail service feature and it’s timer job and then add them back again after the December 2013 CU was applied. When these steps were followed the problem went away.
Delete the Job:
$job = Get-Sptimerjob | ? {$_.Name -eq "job-email-delivery"}
$job.Delete()
Re-enable the “Incoming E-mail”, this will recreate the job
- Central Admin->System Settings
- Configure incoming e-mail settings
- Configure all option as necessary
Confirm the Locktype : None for job-email-delivery
get-sptimerjob job-email-delivery | fl
Restart the timer job across all servers.
TechNet Articles: