Archive
Found an issue [WITH FIX] with SP2010 April 2012 CU : incoming emails not going to SharePoint
Issue :
Incoming emails to SharePoint are all configured properly and emails are being received in the server’s SMTP Drop folder but they stay there and are not picked up by SharePoint.
Troubleshooting :
Looking at ULS Logs the following error is showing :
E-mail cannot be delivered because site is over quota or locked for editing. Site URL: http://xxxx.
Researching :
A quick Google and it seem that CU April 2012 has raised this issue: http://blogs.msdn.com/b/george_bethanis/archive/2012/05/25/sps2010-cannot-send-incoming-emails-to-lists-libraries.aspx
SharePoint incoming email Fix :
Following the steps fixes the issue except for Nintex:
-> SharePoint Central Administration > Application Management > Configure quotas and locks > on the Site Quota Information section > set a limit (i.e: 5000 MB) on this setting: “Limit site storage to a maximum of:” > and then press “OK”.
Nintex issue :
I now work a lot with Nintex workflow and one of the greatest feature in the product is the ability to approve a task via email response called “Lazy Approval”.
The issue with the above is that Nintex drops the Lazy Approval emails in to a HIDDEN library under the Central Administration, therefore we need to set a quota to the Central Admin site as well but as you will experience there no way to select the Central Administration Web app when setting Quota.
Nintex Lazy Approval Fix :
I found the fix on the Nintex connect forum here.
1) get the storagemaximumlevel for Central Administration using PowerShell :
$ca = get-spsite -identity http://sharepointserver:portnumber $ca.quota.storagemaximumlevel
Result should be 00000 since no quota is usually set for Central Admin site.
2) set a maximum quota
$ca.quota.storagemaximumlevel=80000000
No IISRESET is required and email will leave SMTP DROP Folder to be treated by Nintex Lazy Approval in a few seconds once Timer Job restarts.
Conclusion :
Seems that either not many environment use Incoming Emails to Sharepoint libraries or not many have upgraded to April 2010 CU since there isn’t much articles about this, hopefully the next CU will fix this issue otherwise make sure you include this workaround in your Sharepoint and Nintex configuration.
[Update] April 2012 CU was removed and re-releaed however it still does not fix the incoming email, making this look like a definite move to disable it by default.
SharePoint and fun with SP1
Recently I was asked to take a look at a SharePoint 2010 system that was having a few problems. Looking at the patching status it was still running SPS2010 RTM, so the 1st job was to at least get SP1 installed, then the latest CUs on top, and so the fun started…
I downloaded the appropriate service packs, and kicked off the foundation SP1 install and got the following.
The error appeared straight away, no upgrade log was written, nothing in the ULS logs and nothing in the Windows logs.
I used /? switch on the end on the Service Pack file to get the usage options.
sharepointfoundation2010sp1-kb2460058-x64-fullfile-en-us.exe /?
Next I used the log option to have a look at the output of the Service Pack install
C:\patches>sharepointfoundation2010sp1-kb2460058-x64-fullfile-en-us.exe /log:c:\
patches\sp.log
There is quite a lot of information written to the log file, but nothing that pointed to the reason of the failure, next was to extract the patch and see which patch file was causing a problem.
C:\patches>sharepointfoundation2010sp1-kb2460058-x64-fullfile-en-us.exe /extract
:c:\patches\sp
the c:\patches\sp folder now contains the extracted patch files and the EULA text file
Running the patch wsssp1-x-none.msp was giving the following error.
So the Service Pack wouldn’t install because one of the patches inside it didn’t realise that SharePoint was installed, interesting as the error I would have expected to if SharePoint wasn’t installed would have been this one…
I tried running the Config Wizard, but that didn’t help either, after checking with one of colleagues who knows all about packaging software he thought that the failing msp was probably looking for a specific registry key or value.
So I decided to try running a repair from Control Panel, to reset all the original Server settings while not effecting the content or configuration databases (this process ran for quite a long while)
Then I re-ran the Config Wizard, (which now asked about removing the server from the farm).
Finally, after all this the Service Pack would finally install.
Another day done in the world of SharePoint.
Follow @NeilKing41
SharePoint Patching and “Action Required”
The last 2 SharePoint 2010 systems I have looked at have displayed the “Action Required” status for one or more servers in the farm in the “Manage Servers in this Farm” page, which is normally caused by incorrect server patching.
When you apply a Service Pack or CU to your SP2010 farm, you are normally looking at performing a quite straight forward 3 stage process.
Stage 1: Obtain patch:
Download the latest Service Pack or CU from here:
http://technet.microsoft.com/en-us/sharepoint/ff800847#LatestUpdates or use the “Use this page to view the latest patch status for products installed on servers in the farm” link on the CA site in Central Administration > Manage Patch Status
Stage 2: Install Patch
Once you have your Service Pack or CU, you will need to run it on each of the servers in your SharePoint Farm that has the SharePoint binaries installed, there is no special order to do this, but personally I like to run the patch on each WFE in turn, then on the application servers.
Once the patch has installed you will normally be prompted to run the Config wizard, if you are working on a single server farm, run the Config Wizard at this point, if you are working with a multi server farm cancel the Config Wizard and run the patch on each server on your farm.
Stage 3: Config Wizard
If you are running a single server system and have followed the instructions in stage 2, you should be finished. If you are running a multi-server farm you now need to run the Config Wizard to finalize the patch install. I like to run the wizard on the 1st server I patched and let it run to completion, then run the wizard on the rest of the servers in the farm, again there is no particular order to this but personally I like to run the wizard in the same order as I patched the servers, Once finished a quick reboot all round and we are done, and your status should be “No Action Required”
SharePoint (and Project Server) Shenanigans 