Route SharePoint Email from non-prod farms to mail enabled group or SP list.

Why do we need to route emails coming from SharePoint DEV & TEST farms to mail enabled group or SP list. This includes both Nintex and SharePoint alert mails.

 Where this can be useful:

  • When carrying out testing for SharePoint alerts or Nintex workflows to confirm delivery of emails to users – this email routing will help validate this.
  • When we move site collections to non-prod farms from PROD accidental notifications to users will not occur.
  • Preventing emails reaching a larger audience sent mistakenly by a workflow or SharePoint alerts.
  • Gauging which users are active on non-prod site collections and notify them when we plan to implement changes to DEV and TEST SharePoint environment.

Issues this may cause:

  • Any power user/user trying to test something in non-prod will not receive emails, they will have to contact SharePoint Support for confirmation of emails or SharePoint support can forward that email to the user.
  • You need to provide “from address” to an SMTP server to the exchange admin and he can setup a rule to route these to a newly created mail enabled group also mention which group/list need to be part of these mail enabled group to receive emails.

From Address

mail enabled group

Members of the group

DEV FARM: SP2010Dev@contoso.com

SharePoint Dev Alerts

Sharepoint.Support@contoso.com
DEV Nintex: SP2010Dev@contoso.com  
TST Farm: SP2010Test@contoso.com

SharePoint Test Alerts

Sharepoint.Support@contoso.com
TST Nintex: SP2010Test@contoso.com  

“Alert Me” Missing in the SharePoint Ribbon

These is a strange issue that “Alert Me” button Missing in the SharePoint Ribbon but only for a few site collections and for one complete web application. Check the following paths in central administration.

alertme-missing

  • Central Admin –> Systems settings –>E-Mail and Text messages –> Configure outgoing email settingsoutgoingemailsettingsfarm-outgoingemail
  • Also make sure the web application outgoing email settings are filled as well.

webapplication-outgoingemail

But in this case some web applications are showing “Alert Me” button and this I vaguely remembered something with STSADM commands, and this was suggested by me to the customer to disable alerts for any restored databases from prod to test to stop the site collection from sending alerts to users.

There is a STSADM property which is by default enabled and we can turn the property to false for each site collection or to a complete web application.

The following documentation will be helpful to start on this: Here

At the time of this writing these details applies to SharePoint 2010.

 

tags: SharePoint 2010, powershell, SharePoint Alerts, STSADM

Sharepoint – WorkFlow Timer Job Paused

On a random daily check on CA we found workflow timer job in “Paused” state in Central Admin. Multiple of these pointing to each server in farm in paused state. Many blog posts pointing to restarting the timer service on each server and also clearing the timer cache (configuration cache) would resolve the issue.

http://www.sharepointsiren.com/2013/05/sharepoint-timer-job-stuckpaused-fix.html

http://markimarta.com/sharepoint/paused-workflows-in-sharepoint-timer-job-fix/

After the cache is cleared initially the jobs ran for a couple of instances and they were again pausing and the reason was a modified workflow resulting in a “dead end” state. Which was a mistake by the user. Each server processing workflows timer job became “stuck” due to items reaching the “dead end” state. All workflows with pauses or state changes would have ceased to be processed at this stage.

Under normal operations, a workflow is first executed in the World Wide Web Publishing Service (w3wp.exe). After a delay or pause, in which the workflow “sleeps,” it wakes up and is then run by the SharePoint Timer Service (the owstimer.exe process).

 When w3wp.exe is under excessive load, it postpones the workflow. The Timer Service is then used to the continue the process. SharePoint dictates which Workflow Timer service will run the workflow; the operation can occur on any server running the “Microsoft SharePoint Foundation Workflow Timer Service” service. However, when Nintex Workflow is installed, it only deploys the DLLs required to run workflows to WFE servers–specifically, those servers running the “Microsoft SharePoint Foundation Web Application” service.

This issue is discovered by enabling verbose logging both at CA and also at Nintex global settings and also querying for the workflow name and its site collections using Nintex NWAdmin.exe

After the workflow is modified and already the workflows which are started with the broken workflow is cleared and again restarting the timer services on servers with clearing the cache resolved the issue.

This issue is reported on SharePoint 2010 and Nintex 2010

 

 

Tags: nintex workflow, State changes error, workflow timer job paused, sharepoint timer service restart.

Automate monitoring SharePoint and Windows Services

As a SharePoint admin, the most important role calls for monitoring servers and maintain the SLA’s. I guess there will be no second thoughts on this. For an admin as the environment grows to multiple farms and servers at different location it calls for automation – mostly on routine tasks to save time for their personal life and here in I am attempting to address how it did saved me some time. Automate monitor/start SharePoint Services on farm servers. You can script it to check these services at every restart and if you are the unlucky one where some of the services  keep on stopping or unstable you can schedule the the script to check the services and attempt to start them and also email you the status.

So, we are looking at the script to:

  1. Check the services at startup or on scheduled time.
  2. Attempt to start the services if they are stopped
  3. Send an email with the status of the services from each server.

What you need to know before trying this option:  SMTP server or mailhost server (which has to be unauthenticated SMTP).

I had this script, apparently it is been pieced together for my requirements and then scheduled to run on each reboot. How to call this script, 2 files created: Batch file which refers the PowerShell script  (keep both these files in same path)

  1. servicescheck.bat
  1. Servicescheck.ps1

 

 

 

 

 

 

 

 

 

Tags: Monitor Services, Automate Service Monitoring, PowerShell, SharePoint, Automate monitoring SharePoint and Windows Services