Friday, February 10, 2017

SharePoint Alert Notifications Not Working - Checklist for Troubleshooting

Before proceeding with the checklist, analyze and isolate the issue:

  • Whether E-mail Infrastructure is working on your environment
  • Whether in all SharePoint web applications alerts are not working? SharePoint alerts not working for one site?
  • SharePoint alerts not working after upgrade or migration 
  • Alerts not working after restore or Service pack?
  • Alerts not working all the time? or Stopped working Recently?
  • SharePoint alerts not being sent to All the user? or some users? or distribution groups, ad group members?
  • Whether SharePoint alerts not working for document library? list alerts not working? calendar alerts not working ? or everywhere?
  • Only SharePoint daily alerts not working? etc. 
This will help you to troubleshoot the SharePoint email alerts not working issue, quickly.

Here is the checklist for troubleshooting:
1. Check alerts are enabled for your web application:
How to check? execute this stsadm in your SharePoint Server:
Stsadm.exe -o getproperty -url http://SharePoint-web-App-URL -pn alerts-enabled

This should return <Property Exist="Yes" Value="yes" />

If you don't get this, Enable alerts by:
stsadm.exe -o setproperty -pn alerts-enabled -pv "true" -url http://SharePoint-web-App-URL

If its already enabled, try turn off and turn on it back.

2. Is your SharePoint Server configured for Out-going E-Mail settings?
Go to Central Administration > Operations > Click on Outgoing e-mail settings Link under Topology and Services, Make sure you have valid settings for these fields. Usually you have to provide your Exchange server's HUB or any valid SMTP server's address.

3. Is your Exchange server allows SharePoint to Send Mails? 
In Exchange Server, If anonymous Relay settings is not enabled, then you must add your WFE/App Servers to the Exchange Server allowed hosts relay list! Make sure your ALL Sharepoint WFE's IPs are added in allowed Relays or Receive connectors in Exchange Server. If you use multiple domains, add all of them.
http://technet.microsoft.com/en-us/library/cc288949.aspx
Watch the  'DROP' folder in the mailroot of the SMTP server.

4. If you are using SMTP Server for E-mail communication, Make sure SharePoint Servers are allowed to Send Mails and Port 25 is open.Go to SMTP Virtual Server Properties >> Setting >> Access TAB >> Select "All except the list below"

5. Verify the Timer Jobs & Properties:

MOSS 2007:  Central Administration > Operations > Timer Job Definitions (under Global Configuration)
In SharePoint 2010: Central Administration > Monitoring > Review Job Definitions 

Check whether the "Immediate Alerts" job is enabled for your web application. check these properties:
  1. job-immediate-alerts
  2. job-daily-alerts 
  3. job-weekly-alerts
stsadm.exe -o getproperty -url "http://Your-SharePoint-web-App-URL" -pn job-immediate-alerts

The expected output is:

<Property Exist="Yes" Value="every 5 minutes between 0 and 59"/>.  

If you don't get this, run the following command to change its value.

stsadm.exe -o setproperty -pn job-immediate-alerts -pv "every 2 minutes between 0 and 59" -url http://Your-SharePoint-web-App-URL
More info: http://technet.microsoft.com/en-us/library/cc262432.aspx

6. Whether the user account subscribed for alerts has E-mail account associated?
In one of my case, user has two accounts, One normal account and another one for Administrative
purpose. He logged in with Admin account, created alerts, and then complained that he didn't receive
alerts! LOL

7. Try these Resets:
Do stsadm -o execadmsvcjobs. Do restart SharePoint Timer services and IISReset.
Is it happening only to a particular user? try remove/re-add em.

8. Check the Permissions: 
The initial alert is not security trimmed. Whether the user has access to the list or not, He will receive the initial alert. If the user is not getting alert for any changes, then check whether the user has at-least Read permission on the list/library.

If item level permission and Read Access to Only their own items is enabled, Alerts wont work!

9. Re-register the alert template:
Try re-registering the alert template:
stsadm -o updatealerttemplates -url http://Your-SharePoint-Web-App-URL -f  "c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml" -LCID 1033

More info: http://technet.microsoft.com/en-us/library/dd278299.aspx

10. Check your Alternate access mapping
Is your Site URL's/AAM entries changed recently? Check the below tables in your content databases, and verify you dont have any old URL in "SiteUrl" column  in these tables, if you find, replace them.

- ImmedSubscriptions (Stores the alerts for emails that are sent immediately when changes occur)
- SchedSubscriptions (Stores daily or weekly scheduled alerts)
- EventLog (This table contains events for which only non-immediate alerts exist)
- EventCache (This table contains a list of site events for which users have requested alerts. WSS inserts events into this table as they occur)

setting up in the Alternate Access Mappings in Central Admin will correct this issue.

11. Clear the SharePoint configuration cache http://support.microsoft.com/kb/939308

12. Migrated or Changed the Site URLs?
Are you migrated from existing versions of SharePoint/ Changed your SharePoint Site URLs?
You have to update your alerts. Have you performed some database restored in your environment from a different server? Follow my article to fix the alerts: Fix Alerts in SharePoint Migration

13. Export-Import, Backup/Restore:
If you conclude alerts are not working for a entire sub-site but works well with another sub-site, then take the export of the sub-site, delete it, restore it again.

14. Is your SharePoint Up-to-Date?
Make sure your SharePoint is updated with latest service packs/patches.

15. Want to send SharePoint alert to distribution list? SharePoint alert email to distribution list not working?
Make sure your group is E-mail enabled and has at-least read-only permission on the site/list where you are creating alerts. It must be Security group and not distribution list. SharePoint can recognize one users and security groups. So, you can create a Mail for the security group.

Go to distribution group properties and un-check "Require that all senders are authenticated" or create a outgoing connector in Exchange, so that exchange server authenticate SharePoint

Same applies, When you send E-mail from SPD Workflow (or any other workflow). Make sure that the group has at least read permission to the site and the group can be viewed by "everyone".


16. Changes to the user profiles happened wont affect immediately. sync it back.

17. Make sure your timer job account has dbo access to SharePoint content databases.

18. If your Task assignment mails are not delivered, toggle the value for "Send e-mail when ownership is assigned".

19. Task Assigned notification e-mail: If the user synchronized the tasks list with Outlook 2007 the e-mail will not be sent and he will receive the notification in his task pane

20. Content database: Try Re-Attaching the content database (stsadm -o deletecontentdb and addcontentdb)


Alternates: you can simply design a SharePoint designer workflow to send E-mails. or you can have a event receiver to do the same!


Read more:

Sunday, February 5, 2017

Lets talk about SharePoint Auditing and EffectiveAuditMask

 Everyone loves auditing, it fills the content DBs with such useful information. It's like Christmas came early for the SQL storage vendors!!
Seriously, I was attempting to use PowerShell to pull Auditing settings from our farm. Who has turned it on, what trimming settings have they selected, and what items are being audited?
Pretty simple stuff:
(Get-SPSite <siteURL>) | select -expand Audit
Returns something like this for a site with no Auditing enabled
UseAuditFlagCache      AuditFlags      EffectiveAuditMask
———————–      ————-       ———————–
False                                None                 None
Great. Now if you find a site with Auditing enabled, that's where things get really wonky.
If someone has selected just "Opening or downloading documents, viewing items in lists, or viewing item", you get:
UseAuditFlagCache      AuditFlags      EffectiveAuditMask
———————–      ————-       ———————–
False                                View                   View
Oooookkkk, not really a bit-on flag, but let's see where this goes.
If someone enables "Editing item", it looks like this:
UseAuditFlagCache      AuditFlags      EffectiveAuditMask
———————–      ————-       ———————–
False                                Update              Update
And if someone enables "Checking out or checking in items", it looks like this:
UseAuditFlagCache      AuditFlags      EffectiveAuditMask
———————–      ————-       ———————–
False                                3                         3
Well, of course it does. Looks like the helpful folks at Microsoft decided that some Auditing options will return a word, and some will return a bit-on mask. Super helpful, great, thanks. Awesome.
Fear not, I'm here to help, and help I will. Below is a handy table showing you how to figure some of this mess out. If you look at the Audit Settings section under Site Settings, this will show you what you will see from PowerShell, and what the corresponding bit on equivalent is.
Documents and Items:
PowerShell      Setting in Site Settings
————-      —————————
View(4)           Opening or downloading documents, viewing items in lists, or viewing item properties
Update(16)     Editing items
3                       Checking out or checking in items
6144                Moving or copying items to another location in the site
520                  Deleting or restoring items
Lists, Libraries, and Sites
PowerShell                      Setting in Site Settings
————-                       ————————-
160                                     Editing content types and columns
Search(8192)                   Searching site content
SecurityChange(256)     Editing users and permissions
So, using some quick bit on math you can finally start to understand, from PowerShell, what auditing options your happy Site Collections Admins have selected. Now the fun part, go figure out how much space Auditing is taking up…
Open, Edit: 20
Open, Edit, check Out: 23
Open, Edit, check Out, Moving: 6167
Open, Edit, check Out, Moving, Delete: 6687
All Lists, Libraries, and Sites: 8608
All On: 15295
Hope that helps… 

Wednesday, February 1, 2017

Restoring user profile service application with existing databases

Issue: Restoring user profile service with existing database / After restoring a farm from a backup using the Restore-SPFarm PowerShell command the User Profile Synchronization service fails to start
Resolution: To resolve the issue deleted the User Profile Application that was created during the restore process and then recreated it.    To ensure that you do not lose any user profile content there are a few steps that must be followed:
  1. Using central administration, stop the user profile application service on all servers in the farm.
  2. Using central administration, delete the user profile application.   DO NOT check the option to "Delete data associated with the Service Applications".
  3. Identify the names of the user profile, social, and sync databases.
  4. Run the New-SPProfileServiceApplication PowerShell command passing in parameters for: ApplicationPool, Name, MySiteHostLocation, ProfileDBName, ProfileSyncDBName, and SocialDBName.     This will create a new profile service application using your restored profile databases.
  5. Run the New-SPProfileServiceApplicationProxy PowerShell command passing in parameters for: ServiceApplication and Name.   Also include the DefaultProxyGroup parameter.
  6. Start the User Profile Service on Application sever
  7. Run an IISReset command on each server.
  8. Start the User Profile Synchronization Service on the application server.  Wait for 5 – 10 minutes for the service to start.   Ensure that it is started before proceeding.
  9. Ensure that the User Profile Synchronization Timer job is enabled and set properly and then start a full import.
Always remember to test out your disaster recovery plan in a development or QA environment prior to your production launch of SharePoint 2010.