I was setting up Incoming Mails for SharePoint 2013 and like many people on Google, my mails were delivered to the Drop folder and were stuck there. I have solved this and have gained some insights into how Incoming Mails should be configured. This post captures these learnings.

Please note this is for SharePoint 2013 only.

1. My topology and Incoming Mails configuration

In the end the problem was because of a misconfiguration that was not appropriate for my topology. I will therefore first describe my topology and the original configuration.

I have a 4-servers farm with 2 WFEs and 2 Apps servers. The SharePoint Incoming Mails service is provisioned on both Apps servers. One of the Apps servers runs the Windows SMTP Service.

In Central Admin I configured Incoming Mails using the Automatic mode and specified to use Directory Management Service.

2. High level overview of how Incoming Mails works

This is necessary to understand the problem. If configured correctly, then when a mail is sent to Exchange, Exchange routes the mail to the SMTP Server that is specified in Central Admin’s Incoming Mails configuration. This ends up in the Drop folder of the SMTP Service on this server. A SharePoint timer job, namely Microsoft SharePoint Foundation Incoming E-Mail, monitors this folder and processes mails that are delivered to this folder. This timer job is responsible for creating items in your lists/libraries and removing processed mails from the Drop folder. This timer job is scheduled on all servers where the SharePoint Incoming Mails service is provisioned. It is scheduled to run every 1 minute by default.

3. The problem, root cause and the fix

As mails were being delivered to the Drop folder, we can exclude Exchange from the problem, and isolate it down to the SharePoint timer job. In my case, the root problem is because the timer job was not able to access the Drop folder to process delivered mails.

Recall that I have the SharePoint Incoming Mails service provisioned on 2 Apps servers (server A and B). This means that the timer job is scheduled to run on both of these servers. Recall that I also have the Windows SMTP service running on 1 Apps server (server A). This means the Drop folder is on server A.

In Central Admin I also configured Incoming Mails using Automatic Mode. This means SharePoint uses the Drop folder as specified by the Windows SMTP service. By default this is c:\inetpub\mailroot\Drop.

The root cause is because when the timer job is running on server B, it is unable to access the Drop folder on server A. This is probably because it attempts to access it using c:\inetpub\mailroot\Drop, which does not exist on server B.

I created a network share to the Drop folder on server A, switched Incoming Mails to Advanced Mode in Central Admin, and entered the share path (e.g. \\serverA\Drop) for the E-Mail drop folder setting and Incoming Mails immediately worked for me.

Be aware that you will need to grant appropriate permissions to the network share for the Central Admin’s app pool account, and the content web application app pool accounts as per the MSDN article on setting up Incoming Mails.

4. Understanding more about Incoming Mails

OK, so the timer job on server B could not access the Drop folder, but what about the timer job on server A? If the timer jobs are scheduled every 1 minute, the mails shouldn’t get stuck for a long time, right?

Well, this is where things got interesting.

By chance I noticed that even though the timer job is scheduled on 2 servers, it was only executing on server B as shown below.

The job on server A would be rescheduled every 1 minute, but it’d never execute.

I found this post http://www.sharepoint2013.me/Blog/Post/161/Incoming-email-service-on-SharePoint-2013-server-farm-, which explains what’s going on. As a summary, while the timer job can be defined on multiple servers (i.e., on those servers where the Microsoft SharePoint Foundation Incoming E-Mail service is provisioned), it will only execute on 1 particular server. The server that it will execute on seems to be internally set when the Timer Service Recycle job (of the Microsoft SharePoint Foundation Timer service) is executed.

I tested this and it seems to be true. I ran the Timer Service Recycle job and the Microsoft SharePoint Foundation Incoming E-Mail job started executing on the other server (server A) and stopped executing on server B. I do not know how SharePoint picks which server to run the Incoming E-Mail job on.

The Timer Service Recycle job performs a graceful restart of the Timer service. You can read more about it here: http://blogs.msdn.com/b/besidethepoint/archive/2012/01/10/the-timer-recycle-job-job-timer-recycle.aspx. The default schedule for this job is 6:00am daily. It is however disabled by default on my server.

5. Summary and Take Away

So when incoming mails are stuck in the Drop folder, it is likely because they are not being processed by the Incoming E-Mail timer job. In a multi-servers farm, it is best to create a network share to the Drop folder and use this network share in configuring Incoming Mails in Central Admin. This helps to ensure that the Incoming E-Mail timer job can access the Drop location regardless of where it is being run from in the farm. Ensure you have granted permissions to the network share as per the MSDN article on configuring Incoming Mails.