This article is not about how to setup incoming e-mail for SharePoint. A step-by-step how to setup incoming e-mail for SharePoint can be found here.
This article is about one software bug related to SharePoint 2010 and SharePoint 2013 “introduced” by Microsoft starting with November 2014 Cumulative Update (KB2899478 and KB2889944) and for which the fix was not released yet (even if at the moment when I am writing this post, the March 2015 Cumulative Update was released).
Now to provide the exact scenario where the incoming e-mail is affected by the Microsoft software bug part of November 2014.
You will encounter the incoming e-mail issues if your setup is in the following combination:
- You have one of the following builds of SharePoint 2010 / SharePoint 2013:
- SP2013 March 2015 CU (KB2956166: build 15.0.4701.1001) / SP2010 March 2015 CU (KB2956201: build 14.0.7145.5001)
- SP2013 February 2015 CU (KB2920804: build 15.0.4693.1001) / SP2010 February 2015 CU (KB2899558: build 14.0.7143.5001)
- SP2013 December 2014 CU (KB2910938: build 15.0.4675.1000) / SP2010 December 2014 CU (KB2899583: build 14.0.7140.5000)
- SP2013 November 2014 CU (KB2889944: build 15.0.4667.1000) / SP2010 November 2014 CU (KB2899478: build 14.0.7137.5000)
- The document library where the incoming e-mail is enabled has no SharePoint quota defined, or the defined quota template applied doesn’t have defined the sandbox usage quota points.
Sounds crazy, but the software bug is not affecting incoming e-mail in all the cases. It is possible to not notice it, due to the specific situation (configuration + usage) you must have to be affected by it. In my case the incoming was working, but not for all the site collections – so I had e-mails stuck in the drop folder.
I opened a Microsoft Support call and with their help I found out there is a way to bypass this software bug. The Microsoft Support confirmed they will release a fix for this issue in the next Cumulative Update.
The way to bypass the software bug is to specify a sandbox usage quota for your site collections.
Even if you don’t have sandbox solutions, you must specify a quota limit for all the site collections to make sure you minimize the impact this software bug can have over your SharePoint setup.
How to apply the workaround?
Step 1 Make sure you edit the existing quota templates defined on your farm (yes, you have to update all the defined quota templates you are actively using). Central Administration -> Application Management -> Specify quota templates. For each quota template defined, make sure you specify a sandbox maximum usage per day (don’t leave it set to 0 points). The maximum value you can define is 999999 points. Simply set a value higher than 0.
If you upgrade a site collection from SharePoint 2007, the SharePoint upgrade process will automatically assign 300 points as UserCodeMaximumLevel for each site collection (unless you overwrite later the value by applying a defined SharePoint quota template). This means, this software bug is not affecting the recent upgrade SP2007 site collections.
This step will help you to make sure you will not be affected by the software bug for the new created SP2010/SP2013 site collections (if you have defined a default quota template for your SharePoint Web Application).
Step 2 Defining new values for the quota templates will not automatically update the quota for the existing site collections. Either you re-apply the quota for each site collection through Central Administration, or use the following PowerShell script to specify a maximum sandbox usage value for all the site collections where currently the value is set to 0.
Start-Transcript ('incoming email fix.txt'); if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null) { Add-PSSnapin "Microsoft.SharePoint.PowerShell" > $null; } $webapplications = Get-SPWebApplication; foreach($webapplication in $webapplications) { foreach($site in $webapplication.Sites) { if($site.Quota.UserCodeMaximumLevel -lt 1) { Write-Host $site.Url 'has UserCodeMaximumLevel lower than 1 => set UserCodeMaximumLevel higher than 0.'; try { $site.Quota.UserCodeMaximumLevel = 999999; Write-Host 'Sandbox quota set.'; } catch { Write-Host 'Couldn''t set UserCodeMaximumLevel higher than 0 for' $site.Url -foregroundcolor red; } } } } Stop-Transcript;
Thank you Viorel! After spending an entire day I found your blog post and the solution!
I came across this blog.. Good info for any of those facing this issue within their Site Collections. To clarify a bit, this issue was actually introduced in December 2014 CU in both 2013 and 2010 version of the product. This has been resolved in the April 2015 CU for SP 2013 and the expected fix for SP 2010 is in the May 2015 CU… just FYI
Thank you so much for this solution! It works again… Finally…
Spent a whole day with this bug, thanks!
many thanks….It really saved a headache 🙂