THE SHORT STORY
This issue presented itself in a rather unorthodox fashion. Contractors (with external email addresses) that were collaborating with project managers were not receiving SharePoint email alerts. However, they were receiving the “You have successfully created an alert” email.
This issue was only present on specific site collections.
The solution was to enable the index server as a “Receive Connector Hub Transport” in Exchange.
This issue was quite perplexing and to fully explain it, I will need to tell you a little bit about the environment.
One web front-end server (wfe) and one index server (index) connected to a SQL 2005 instance. Thirteen site collections and thirteen content databases (each site collection resides in a content database).
One afternoon, it was reported that alerts were not working for some contractors that project administrators were collaborating with. I had the Active Directory admin setup at test account for me (ExternalTest) with an external email address. I was not able to reproduce this on my test site collection with a hotmail address, so I went about troubleshooting this as if it were an email issue. Since the contractors were receiving the “You have successfully created an alert” email, I made the assumption that he emails were being sent. I asked the contractors to check their junk mail but the alerts weren’t there. Assuming it was still a mail routing issue I worked with the contractor’s exchange admin to ensure the emails were not being blocked at Exchange or maybe anti-virus. That was not the issue either.
As I dug in further the issue seemed odd in the fact that while I could not reproduce the issue on my test site, I was able to reproduce the issue on a few different site collections.
So to recap here are the specifics:
- The ‘ExternalTest’ account would receive the “You have successfully created an alert” email for all sites collections.
- The ‘ExternalTest’ account would receive alerts from three of the thirteen site collections.
I will admit now that I was forced to call Microsoft. Unfortunately, troubleshooting this took hours. The resolution was worth it and I will try to cover the details so anyone else troubleshooting this can fix it. I worked with Pious Panangadan and he was great.
The first thing to check is to ensure the external user has access to the site.
If the List or Library does not inherit permissions from the site, ensure the user has at least read permissions.
If the Site does not inherit permissions from the Site Collection, ensure the user has at least read permissions.
While working with Pious at Microsoft, I was able to resolve the issue on a few specific sites by adding the user to the List, Library, or Site. One of the many things I learned was the SharePoint Unified Logging Service will verify that the alerts are being generated.
The second thing was to ensure the timer jobs were running properly. In Central Administration > Operations > “Timer Job Status” look for any ‘Immediate Alerts’ jobs that are failing. None were failing for me but there was a hint of the problem. The specific job was running on TWO servers..
When a user subscribes to an alert (or someone else subscribes them) an email is immediately generated and sent. When something in the List or Library changes, an alert is created, but the alerts are not sent immediately. The email is generated by the timer service. For the purpose of this discussion, I will be referring to “Immediate” alerts. Although it is possible to customize when the timer job runs, by default the timer job runs every five minutes. Therefore, if an item is added, deleted or modified at 10:01am the email alert for that item will be sent at 10:05am. Not quite ‘immediate’ huh?
Go to SharePoint Central Administration > Operations and in the Logging and Reporting section choose “Diagnostic Logging”. Set the logging as follows:
For “Select a category” choose “All”
For “Least critical event to report to the event log” choose “Error”
For “Least critical event to report to the trace log” choose “Verbose”
Note the path of the trace log and then reproduce the issue.
Quick side note: Check the path on all the servers in your farm. Since both wfe and index had the timer service running on them, they each were generating the log file.
Knowing the timer job runs every five minutes, find the log file that should have the alert emails being generated in it. Open that log file and search for “Alertsjob results for immediate delivery”. Verify the time is the expected time and note how many alerts passed filtering and trimming. Two line excerpt of the log file below:
- Alerts being filtered means they are being filtered for exchange rules
- Alerts being “trimmed” means there is security trimming going on. That means the alert cannot be sent to the user because the user does not have access. That means you missed the step “The first thing to check…” above.
For my troubleshooting all the alerts were passing filtering and trimming. That is how Pious knew the alerts were being generated by SharePoint. Now we are back to troubleshooting email. yay..
Fortunately for me, Pious had some Exchange and SMTP background and we proceeded to test outbound mail flow on wfe and index by following Microsoft’s Knowledgebase Article 29770. Using the sample.eml file I discovered that wfe was sending email but index was not.
Now I had to go back to the Exchange admin to determine why one server can send email but the other server cannot. Now my knowledge of Exchange is limited and I will probably slaughter the proper terminology but here is what we found.
In Exchange Management Console under Server Configuration there is a category called Hub Transport. There was a Receive Connector called SharePoint and inside that Receive Connector there is a list of IP Addresses from which the Exchange Server will accept email. There was an entry for wfe but no entry for index. The Exchange Admin added index to the “Receive mail from remote servers” and alerts started working. screenshot below