Grabbing EML files from drop folder before job-email-delivery gets them

Often when troubleshooting incoming email problems in SharePoint, we would temporarily disable the Microsoft SharePoint Foundation Incoming E-Mail (job-email-delivery) timer job, then send an email and watch the folder for an EML file to show up.

Alternatively, you can register a FileSystemWatcher to listen on a Created event. Then, this code can copy out the EML file to some safe place before job-email-delivery gets it.

To install the listener:

$destination = 'c:\Windows\Temp\maillogs' # Make sure your powershell user can write here
$dropFolder = 'C:\inetpub\mailroot\Drop' # Drop folder as configured in SharePoint

$filter = '*.eml'

$fsw = New-Object System.IO.FileSystemWatcher($dropFolder, $filter)
$fsw.IncludeSubdirectories = $false
$fsw.NotifyFilter = [System.IO.NotifyFilters]'FileName,LastWrite' # seems to need this to avoid some IOExceptions

$onCreated = Register-ObjectEvent -InputObject $fsw -EventName Created -Action {
  Write-Host "$($Event.TimeGenerated) : Incoming email file - $($Event.SourceEventArgs.Name)"
  Copy-Item $Event.SourceEventArgs.FullPath -Destination $destination -Force -Verbose
}

To remove the listener:

Unregister-Event -SourceIdentifier $onCreated.Name
$onCreated.Dispose()

Unknowns:

• Does not account for large incoming files that are temporarily locked while being copied
• Not sure if this causes problems if job-email-delivery tries to access (or even remove) file while Copy-Item is being called.
• Not sure if this is guaranteed to happen before job-email-delivery
• Not sure of the performance impact

Finding Alias for SharePoint Email Enabled Lists

As usual, there are several ways to do this that can be readily found via a search

Powershell: Loop through each Web Application, Site Collection (SPSite), Subweb (SPWeb), List. Then look in the EmailAlias property for what you are searching. In large environments, I suspect that this would be very slow and resource intensive. Here is a Foreach-Object pipeline that would do the trick:

Get-SPWebApplication | ForEach-Object {$_.Sites} | ForEach-Object {$_.AllWebs} | ForEach-Object {$_.Lists} | Where-Object {$_.CanReceiveEmail -and $_.EmailAlias} | Format-Table EmailAlias, Title, ParentWebUrl -AutoSize

SQL: One way is to essentially do the above but via the content databases, but this one also seems resource intensive:

USE [Some_Content_DB]
SELECT tp_Title, tp_EmailAlias, FullUrl
  FROM [dbo].[AllLists] lists
  LEFT JOIN [dbo].[AllWebs] webs ON lists.tp_WebId = webs.Id
  WHERE tp_EmailAlias IS NOT NULL

SQL: I decided to see what the Microsoft SharePoint Foundation Incoming E-Mail timer job does (job-email-delivery) since the timer job should be quite fast. Looking at the code, I can see that it calls the proc_getEmailEnabledListByAlias stored procedure. Diving into that, I see that this may be a better query:

SELECT * FROM [SharePoint_Config].[dbo].[EmailEnabledLists] 

However, I did also run across a post mentioning that it is possible the Config database and the Content database can be out of sync. So, it may still be necessary to choose the correct method depending on the problem one is trying to tackle.

Enabling incoming email on SharePoint 2013

I am running SharePoint 2013 RTM on one of my demo servers and want to enable incoming email. The configuration is exactly the same as in SharePoint 2010:
Setup your SMTP server to receive email
Set "Enable sites on this server to receive e-mail" to Yes
Verify firewall settings to allow connections to port 25

However, after checking all this, my incoming email was still not making it into my lists. I can see the incoming email message sitting in the C:\inetpub\mailroot\Drop folder and it is not being processed.

By chance, I decided to set "Enable sites on this server to receive e-mail" to No, save and then back to Yes. Then miraculously, the incoming email is now being processed. I have now seen this exact behaviour several times with my SharePoint 2013 instances.

User Profile Synchronization not synchronizing email address

I found this on my new SP 2013 installation. After a user profile synchronization, my email addresses were not coming over from AD. Doing some poking around, I found that the user profile property was not mapped to the correct attribute.
To correct:

1. Go to Central Administration->Manage Service Applications.
2. Go to your User Profile Service Application
3. Go to Manage User Properties
4. Scroll down to Work email (under the Contact Information Section)
5. Edit Work email
6. Remove the existing Property Mapping for Synchronization mappings. They were inexplicably set to proxyAddresses (aCSPolicyName).
7. Add new mapping to the mail attribute
8. Start a Profile Sync
9. Save and OK

It looks like just a simple profile sync would not work. You actually have to update the email addresses of each user and then do a sync. Argh!