This will be the first post about “troubleshooting MOSS/WSS” on a series, defined by topics and Issues. Once I have created several posts of this kind, I’ll push up a main page with a repository of single links to each topic and its content.
ALERTS in SharePoint
I think one of the most reported and popular issues within SharePoint Server 2007 / WSS
(and have been also before on SPS 2003) is: the “Alert problem”.
Well, when we’re talking about “alerts” it usually means the “Notification email” that is sent to a user.
i.e. this is mostly set on a document library where users configuring their “Alerts” for getting notified on certain actions like changes on documents, new added, deleted, modified etc. This can be set to an “immediate alert” which sends out immediately emails due to the configured actions that happened and/ or
The typical issue is this one:
You create an alert on a document library. You get the notification that the alert has been created.
But you don’t get any alerts sub sequentially
So what I‘ll try to tell you today is a little “toolbox“ you can use on troubleshooting your environment while investigating problems with your alerts.
First of all, we should split of some wording when we’re talking about “Alerts”:
- the initial email, sent to you with notification that you have set and/or created an alert
- the following emails (subsequently) sent to you, when you have configured to be notified on any changes to a document, Item, List entry a.s.o.
- the search based alerts …
- the workflow initiated email alerts for i.e. assigning you a task.
As you see, we may handle several different kinds of “Alerts” and also why or if they sent or not.
Therefore it is often quiet difficult to troubleshoot the cause of those issues as they may vary each time.
From my daily business I often have very tricky cases and issues. But sometimes and despite the Internet,
some “simple resolutions” also may work based on native settings or better let’s say:
”why can’t we see the forest about all those trees in front of it?”
– sounds simple, doesn’t it? But I can hear also some “uuuhh yeahhh oooahhh” but what’s the joke?”
Let’s check some examples where the cause and resolution were quiet simple but not noticed on the first research:
Issue 1: “Some email alerts are sent but some others are not…”
Problem:
We had users registered for alerts. The “initial email” was sent to the user, notifying him that he just created an alert.
Now another user changed the document/item you marked for an alert but you don’t get it!
Resolution:
The resolution was as simple as seeing the “forest behind the tress” ;-)
When you have typically a load balanced environment and also using an exchange server for all email traffic,
you should have a look also into the “mail relay settings of the SMTP Server”
Cause:
The IP addresses that were configured to allow relay did not include the IP address for one of the front end servers.
Adding that IP address resolved the problem.
Issue 2: “All users are getting alerts but only one user not”
Problem:
- In this case, just to keep it short, it was Outlook causing it and moved all email alerts into the “junk mail folder” of the affected user
Simple, isn’t it?
Ok, but this is “fortunately” not the usual case and should be only to show up how troubleshooting sometimes can be so easy
when you’re able to “see the forest BEHIND the trees”.
Coming back to some more difficult and more interesting causes of almost similar problems: Alerts are not working…
1. Migration Issue:
One common issue regarding suddenly not working email alerts can occur after migrations and/or detach/re-attach databases to a different web application.
For this you may find a little sample code chunk here, which should you help to fix such an issue:
E-mail notifications for alerts are not sent when content in a migrated list or in a migrated document library changes after you perform a database migration to upgrade to Windows SharePoint Services 3.0 (KB 936759)
Additionally you can also try to fix it by using the new "stsadm -o updatealert" command and the SharePoint Administration Toolkit v4 (x64 version) ; (x86 version).
The cause here is that the issue occurs if the URL of the Windows SharePoint Services 2.0 server differs from the URL of the Windows SharePoint 3.0 server. For example, this issue occurs if the URL of the Windows SharePoint Services 3.0 server is http://ServerNameVersion3, and the URL of the Windows SharePoint Services 2.0 server is http://ServerNameVersion2.
2. setproperty- Issue:
Another cause also mostly occurring after migrations is the missing or not correct set property value for the alerts at all or in particular on your site-url.
To check those properties you just open a command box, navigating to the 12-hive BIN folder (by default: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\…) and run STSADM command line tool
Once on 12-hive, type in the following commands to check all related property settings:
stsadm –o getproperty –url http://YourURL –pn alerts-enabled
-the expected result should be <Property Exists=”Yes” />
stsadm –o getproperty –pn http://YourURL –pn job-immediate-alerts
-the expected result should be <Property Exists=”Yes” Value=”every 5 minutes between 0 and 59” />
where the Value type may vary.
When the properties are not set correct or even set but due to migrations, database restore or detach/re-attaching it, the alerts may stop working for no obvious reason.
Resolution:
Run the stsadm commands to “set” the properties correct or just to trigger SharePoint once more to processing it.
stsadm –o setproperty –url http://YourURL –pn alerts-enabled –pv True
stsadm –o setproperty –url http://YourURL –pn job-immediate-alerts –pv “Every 5 minutes between 0 and 59"
You can specify for the property “job-immediate-alerts” one of the following values:
•"Every 5 minutes between 0 and 59"
•"Hourly between 0 and 59"
•"Daily at 15:00:00"
•"Weekly between Fri 22:00:00 and Sun 06:00:00"
Please see here for options and syntax of the commands:
Alerts-enabled: Stsadm property (Office SharePoint Server)
Job-immediate-alerts: Stsadm property (Office SharePoint Server)
3. Scheduled Alert Issue:
Another finally very simple cause is that SharePoint for some reasons sometimes needs to be “reminded” on what’s its job on alerts ;-)
latest I had the case with problems on not sent “scheduled alerts”. The initial alerts as well as the immediate alerts were sent properly but no scheduled alert (which is a summary of certain changes, notified daily, weekly etc.) received the user.
After extensive troubleshooting and research we finally just ran again a stsadm command to re-register the alert template on the server and “oh wonder”,
suddenly the alerts worked again.
Resolution:
Run stsadm -o updatealerttemplates -url http://YourURL -f C:\Alerttemplates.xml –lcid 1033
Please see here for options and syntax of the commands: Updatealerttemplates: Stsadm operation (Office SharePoint Server)
First Troubleshooting steps:
- Check your Outgoing Email settings on SharePoint / SMTP Settings on WFE/IIS and/or Mail relay permissions and restirictions
- Check if email notficiatiosn and alerts are fired only partly (immediate but not scheduled), if the initial email at all is delivered and exclude any Outlook client problem (junkfilter, blocklists, etc.)
- In SharePoint on Central Admin page, you’ll see under “Operations” the Timer job Definitions and status. First of all, check if the timer jobs finished successfully at all.
- Check the alert properties via stsadm, if they’re set properly
- Re-register the alerttemplate again
- Check if the issue only occurs on a particular site collection, web application
(to test,this, just create a brand new Web app, Sitecollection and leave all on default. Create alerts as applicable and check for delivering)
- If the alerts are fired on a new web app/Sitecollection, then consider the effort to just export from faulty site and import to working site your content
- If the alerts are not fired at all, use Network Monitor, Process Monitor traces, to see if any email at all arrives your mail relay/Exchange server or not
- If the alerts are not working only on certain libraries or sub sites or even just randomly, check for custom event handler or other parts that you may implemented or changed to performing email alerts
Additional Links and resources:
Alerts in Windows SharePoint Services
SharePoint Alert Manager
Another very good blog from my colleague Victor Butuza describes the topic "Search based Alerts"
with some further hints and tips on troubleshooting alerts to be fired on search results!
Some Technical details on Alerts:
Once you have done all the previous investigations and tests but still no glue or idea what may causing your alerts issue, you can dig a bit deeper into the SharePoint Mysteries:
Alerts are processed by the OWSTimer job. In central admin you may see just the “Immediate alerts” job, but this one processes both, the immediate and the scheduled alerts at intervals of every 5 minutes by default.
To follow the trace of an alert process you can look into the content database tables on your SQL server.
The interesting tables here to review are as follows:
ImmedSubscriptions (records the immediate alerts settings)
SchedSubscriptions (records the scheduled alerts settings)
EventCache (records all events in SharePoint, so either the alert changes)
EventLog (This table contains events for which only non-immediate alerts exist)
EventSubsMatches (records the timestamp when a scheduled alert has to be processed by the timerjob)
TimerLock (records the server that processes the timerjobs)
First of all go to Central Admin page and screw up your Diagnostic (ULS) logging to “verbose - All Errors”.
Start repro your issue by creating an alert (immediate and/or scheduled) and note the timestamp you started as well as the timestamp you configured the scheduled alert to be fired.
Perform some actions like changes, deletions, uploads etc. and note the timestamp of changes and wait about 5-10 minutes
Check if you received the alert notifications (Initial email, immediate alert email)
Check on SQL Server if you can find your alert by using these queries:
select * from [Content_DB].[dbo].[ImmedScubscriptions] where [UserEmail] = ‘User.email@domain.com’
select * from [Content_DB].[dbo].[SchedScubscriptions] where [UserEmail] = ‘User.email@domain.com’
select * from [Content_DB].[dbo].[EventCache] order by [TimeLastModified]
select * from [Content_DB].[dbo].[EventSubsMatches]
- Can you find your alerts in “ImmedScubscriptions / SchedScubscriptions” table?
- Do you have a related record in EventCache due to the Timestamp (TimeLastModified) you noted from your repro?
- Do you see the record for scheduled alert in the EventSubsMatches table
Check now your ULS logs (by default located at (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\logs) for entries like that:
[…] …Begin invoke timer job Immediate Alerts, id … […]
[…] …AlertsJob loaded 9 of 9 event data records… […]
[…] …AlertsJob loaded 5 of 5 subscription records… […]
[…] …Alertsjob results for immediate delivery: 9 prematches, 9 passed filtering, 5 of 9 passed security trimming, 0… […]
[…] …Alertsjob results for scheduled delivery: 0 prematches, … […]
[…] …AlertsJob processed 0 daily notifications … […]
[…] …AlertsJob processed 0 weekly notifications … […]
[…] … … […]
- Can you see any records indicating that your alerts are processed at all?
Check your Event log for suspicious errors related to the timeframe and probably containing phrases like “exception, HResult errors, etc.”.
Check if you are on an almost actual patch level as probably the cause of your issue already has been fixed in one of the last updates?
So if all those steps are don’t get you closer to the cause you are at least much more better prepared for the next step on calling Microsoft Support for assistance.
With all these troubleshooting steps done before you can provide all these actions to the support engineer and this may speed up the resolution as the Support Guys then can go directly and already narrowed down to a particular area with very deep troubleshooting steps for you!
So hopefully this post could help you somehow. I’ll be on updating this post whenever some new or deeper insights can be published to get this topic a bit more structured in depth and usage.
Stay tuned ;-)
Steve Chen from daily business and the SharePoint Mysteries…
