This is SharePoint 2013 in built bug. We need to apply this solution after load balancing. We observed load balancing of multiple web fronts environment for 2007, 2010 and 2013. In MOSS 2007 and 2010, Incoming email service is perfectly load balanced. When more than one front-end server is set up to process incoming email messages on a MOSS 2007 and SharePoint 2010 farm, all of the WFE servers can process email messages and can fail over to any other server. Where as in SharePoint 2013 environment, we use shared/network drop folder when incoming email service runs in multiple WFE.
This article will describe the following points –
- Impact of the Issue
- Investigation on this issue
- Root cause of this Issue
- Solution for this Issue
Impact of the Issue :
When multiple WFEs will be connected through load balancer in SharePoint 2013, we will not be able to do load balance for incoming email service as still we can run incoming email service in multiple WFE. It means that if one server in which incoming email service timer job is running will be down then incoming email will be stopped working for whole farm.
In SharePoint 2013, Incoming email timer job is running in only one WFE server, never run on multiple WFE if still the incoming email service is configured to run on all WFE.
Another point is – if this service will run in multiple load balanced WFE server in SharePoint 2013, few email will be delivered correctly (server in which timer job is running) and few will be stuck in drop folder (server in which timer job is not running)
Preliminary investigation for Incoming Email service
From the above impact of the issue we can understand that timer job is mainly guilty for this type of issue. Incoming email service timer job is responsible to deliver email from drop folder to SharePoint library.
In 2007, we found that Incoming email service timer job is running in all WFE servers at same time when it is scheduled.
In SharePoint 2013, Incoming email timer job is running in only one WFE server, never run on multiple WFE if still the incoming email service is configured to run on all WFE.
Root Cause of this Issue
In Moss 2007 and SharePoint 2010, the Incoming Email service timer job had a SPJobLockType of None, which means that the job ran on all servers in the farm, given the Incoming Email service was provisioned
We can also find out which Jobs have a lock of type none run once on each server in the farm. Because each server in the farm has one timer service instance, a job intended to run on every server does not need to take any locks – each server simply knows it can run the job without further concern. We need to use this power shell command –
Get-SPTimerJob | ? {$_.LockType -eq “None”}
In SharePoint 2013, that SPJobLockType has changed to Job, which means it only runs on a single member in the farm. This is a problem for those who wish to use round-robin MX records. While in SharePoint 2010, you could have multiple SharePoint servers, using equally weighted MX records servicing Incoming Email requests, in 2013, you can only have a single server servicing Incoming Email requests.
For this case we can use –
Get-SPTimerJob | ? {$_.LockType -eq “Job”}
There are 3 Locks available.
- SPJobLockType.None — if you set it none, the instance will run in all the available servers in the Farm (e.g. Application Server Timer Job)
- SPJobLockType.ContentDatabase – this will cause 3 instances to be running in each of the Web-Frontends.
- SPJobLockType.Job – this will cause only one instance of the job to run on any of the front-end servers. (Note: it is possible to see multiple instances listed in the Job Status .. but if you look at the time it was last run.. only one would have run lately)
This is a Microsoft SharePoint 2013 in-built issue
Solution for this Issue
Microsoft has already released a Hotfix for this issue in December 10, 2013.
Please click on this URL for reference – http://support.microsoft.com/kb/2837677/en-us
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 its 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.
After implementing all the steps now, everything is working fine in the environment.
