This is a blog for email admins, but frequently email admins are called into troubleshoot systems that want to use our email systems to send and/or receive email. One of the more critical services that will want to use our email system, and that can be tricky to troubleshoot, is SharePoint.

Microsoft’s SharePoint server can generate a lot of email. Notifications of group assignments, permissions assignments, workflows, and alerts can all cause SharePoint to send email out, and most companies want this email going through their Exchange or SMTP relay, as opposed to going straight out to the Internet using the IIS SMTP service.

If you are engaged to troubleshoot email relaying from SharePoint, you will want to have an idea of where things are configured, how they can go wrong, and how to troubleshoot them. This post will start with the basics on the SharePoint server and work its way outward. Keep the SharePoint admin nearby, as some of these things may require them to show you settings within SharePoint or to make changes and test.

1. Check the basics; name resolution and connectivity
   Too many times have I seen hours burned troubleshooting obscure code or script files, only to find that DNS wasn’t set up properly or the firewall ACL that they were absolutely certain was in place, wasn’t. Assuming your company has a designated SMTP relay, get on the SharePoint Web Front End and make sure you can resolve the name, ping it, and connect to it on TCP port 25 using TELNET or TCPING.
2. Make sure the SMTP relay will accept email from the SharePoint server
   If you aren’t sure how to do that, you want to have the TELNET executable on your server, and you can follow the steps in this post. Make sure that you see a 221 after your QUIT. If you are using Exchange as your relay, and it has not be set up to support unauthenticated connections internally, check out this post for the steps to add a listener for your SharePoint server. If you don’t see the 221, then your problem is probably on the SMTP server and not in SharePoint. Assuming you did get the 221, keep going.
3. Verify that AD is set up correctly
   SharePoint depends upon Active Directory for most of the information about users. Make sure that any users who are not receiving email have the correct email address populated in the properties of their email account. If they do not, correct that, ensure that AD replicates to any domain controllers in SharePoint’s site, and then have the SharePoint admin start a new crawl to get the updated information.
4. There are several ways to configure the SMTP server in SharePoint, but the easiest way to see how it is currently configured is to use SharePoint Central Administration. Have the SharePoint admin launch CA, browse to System Settings, then E-Mail and Tex Messages (SMS), and click Configure outgoing e-mail settings. Verify that the settings there are correct for your environment. Note that there is no place to configure authentication; your SMTP relay will have to accept unauthenticated connections.

If the testing in step 2 worked, your users’ email addresses are properly set up in AD, and your SharePoint server is properly set up in step 4, then try to send an email again, and watch the inbound SMTP queue on your mail server. Odds are the messages are making it from SharePoint to the mail server, and then failing. But the basics will solve more problems than not with SharePoint sending email, and the steps above will make sure you cover all of that.

Be Sociable, Share!

•