Before I get into the particulars, here's the basics of our configuration:
Web-frontend: PORTAL.company.com
Index/app server: INDEX.company.com
We currently receive mail at @company.com, which has been floated up to Office 365. Our email-enabled lists receive mail at @portal.company.com, and we create Contacts for those addresses in Exchange, but we don't publish them in the Global Address List. Instead, we create a Distribution Group and put the Contact in there, and then provide the Distribution Group to the users, so that if we need to change the address in SharePoint, we can do that somewhat painlessly.
PORTAL doesn't actually process the mail. As a performance measure (probably a very tiny one, but I digress), we actually process inbound mail on INDEX. PORTAL receives the mail, but a scheduled job on PORTAL shuttles the mail into the Drop folder on INDEX every minute, where the Microsoft SharePoint Foundation Incoming E-Mail service runs. Alerts and other notifications are also sent from INDEX.
Now that this is all out of the way, here's the situation. We don't publish an MX record for PORTAL.company.com - instead, our on-premises Exchange server would handle all mail for *.company.com and route PORTAL.company.com messages appropriately. This way, nobody from the outside world can spam our SharePoint farm directly.
In order to set this up, we had to set up a new inbound connector and outbound connector for SharePoint in FOPE (Forefront Online Protection for Exchange). If you're the SharePoint monkey and haven't really gotten into the depths of Office 365, you can access FOPE by logging into your O365 account, then in the top-bar (assuming you're an Office 365 Administrator), click Home, then Admin (Admin is not directly accessible from the mail window).
On the Admin Overview page, in the main content area under the header "Microsoft Office 365", look for the Exchange section, and click Manage. This opens up a new screen which is the Exchange Online administration screen. In the menu on the left, you should be on "Users & Groups". Click "Mail Control". After the page loads, on the far righthand side, you should see, under the header "Additional Security Settings" the link for FOPE. Click this link and you'll be in FOPE.
You may get a notification that your session has expired. This happens a lot. If so, *close Internet Explorer completely*. You'll need to log into Office 365 all over again, even if you just started your Office 365 session from scratch. It appears that FOPE tracks its sessions independently and doesn't clear them on exit, so when you load FOPE and it finds an expired session, it forces you to load all over again.
Anyway. Now you're in FOPE.
In the context of FOPE, "inbound connectors" mean mail inbound TO the server. So, from a SharePoint context, you'll configure an "inbound connector" for your outbound mail, and for your mail incoming to SharePoint, you'll configure an "outbound connector".
Let's do inbound first. A wrinkle, however.
In the past, SMTP on INDEX didn't need to authenticate itself to Exchange by virtue of already being inside the network. This is probably bad practice in a large organization, but since we're a small shop and only have one Exchange server, it's easily monitored for nefarious activities.
Microsoft will obviously not be so trusting, so we need to configure a secure connection to allow for our server to deliver messages to Office 365. This actually requires us to add an additional user to Office 365 for the purposes of being the delivery proxy for SharePoint's email. So...one E1 license later, and I now have a username and password for use with the connector (I also configured this account to route all of its incoming mail to the SharePoint Administrators distribution group so that if anyone replies to an alert or such, we'll all see it).
On INDEX, IIS 6.0 Management, right-click on your SMTP server, select Properties. Go to the Delivery tab, and we'll be changing settings on all three of the buttons at the bottom.
First, Outbound Security.
If you aren't already using TLS, you will need to be now, so be sure to enable that. You'll also enter the credentials for your new Exchange Online user.
Next, Outbound Connections.
Make sure to change the TCP port since you'll now be using TLS. If you need to punch holes in
Last, Advanced Delivery.
The Smart Host field will have your client-specific smarthost. You'll probably recognize it with the "pod" prefix, but if that changes in the future, you can locate the smarthost information through the Office 365 page in the POP/IMAP/SMTP settings shown in the connection information.
Once you've made the SMTP changes, you'll also need to change SharePoint's mail settings to match.
Now that you've done things on the SharePoint side, time to set up FOPE. Note that FOPE doesn't have to be done last, I just saved it for last.
First, the Inbound Connector (remember - outbound from SharePoint!)
And then the Outbound Connector:
Once these connectors are configured, you will now need to Enforce them in FOPE. Enforcing the connectors means that the changes you've set up will take effect.
After you do this, test your mail setup, because you should be done!
Now how does the other way works? We have Sharepoint in Cloud and Exchange On premise.
ReplyDeleteHow does Sharepoint online know that i have an Exchange onprem for creating a site mailbox if i dont have DirSync setup ?
I've been thinking about this for a while but I'm not sure I can help. I'd love to, but I'm not sure you can do that in SharePoint Online, seeing as how you probably won't have that kind of access to Central Administration to make those changes. Email configuration is farm-wide, not on the Web Application level, and in a shared tenancy environment, you're probably on a common farm rather than having your own farm.
ReplyDeleteAt the very least, I've got an Office 365 account and I don't recall having the ability to configure the farm to use a specific mail server. We also don't have Exchange on-premise any more for me to attempt to test a configuration.
Hi Drew,
ReplyDeleteUnfortunately this tutorial did not work in my case.
I use SPS 2013 and Exchange Online.
My FOPE says:
451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to Connect
What should be done ?
Hi Michael,
ReplyDeleteThis is for email going from Exchange Online into SharePoint on-premises, correct? Just want to make sure.
Great work - but the O365 portal seems to have changed quite a bit since this tutorial was made. Do I have to add the subdomain in my AD before configuring this or is it sufficient to tell O365 to forward *@sub.domain.com to the SMTP server running on the SharePoint 2013 server?
ReplyDeleteChristian - the subdomain shouldn't be part of AD, per se, because DNS is generally independent of your Active Directory configuration. But otherwise you're correct - if you have a web application that lives at sub.domain.com, then you should be set. The important thing is that your SharePoint server needs to believe that it's operating at sub.domain.com, because SMTP will dump the mail in the Inetpub/Drop folder, and that's where SharePoint looks for the inbound messages (and then matches them against email addresses registered in your web applications.
ReplyDeleteAlso, you are correct - I haven't had a lot of material to post about lately but I should probably write up a new version of this article to correspond with Wave 15. Thanks for posting!
Thanks for your reply,
ReplyDeleteI have followed the instructions but I get an error when sending e-mail to a sharepoint library (test@sp.domain.com):
" Remote Server returned '530 5.7.0 Must issue a STARTTLS command first' "
I have added a certificate to the server which appears in IIS 6 - SMTP Virtual Server - Properties - Access - Secure Communication where I have checked the "Require TLS encrytion".
I have also tried disabling the TLS on the SMTP server and changing the security settings of the outbound connector in Office 365 to "Trusted Certification Authority" instead of "Opportunistic TLS". I then get this error:
"Remote Server returned '550 5.7.1 Unable to relay for test@sp.domain.com' "
Have you encountered any of these errors? Any suggestions greatly appreciated :)
Christian,
ReplyDeleteApologies for the late followup. Since Heartbleed, I've changed my Google account passwords and haven't incorporated the new credentials into my notifiers, so I haven't been checking them as often as I should, and for that I apologise.
I have Office 365 set to use opportunistic TLS. There is a certificate installed but I'm not requiring it. The server's external IP is set as a smart host in Office 365. That should be all that's needed.
Opportunistic TLS means that it'll *try* to use TLS, but won't force it, meaning that the mail can be ferried plaintext. I haven't tried to force it over yet, perhaps I will sometime.
Try switching back to Opportunistic and uncheck the "Require TLS encryption" option and then see what happens. Also verify your relay settings. I don't have any filtering on the relay options.
we were able to configure outgoing email but need help to configure incoming email? what steps we have to follow so that the mail should reach SP doc lib
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteI have configured the SMTP at the domain (mydomain.xxx.xxx), and all goes good. Because the email can be sent when I create a test TXT file and drop it into PICK UP folder of the MailRoot.
ReplyDeleteIn the "Outbound SMTP Server" of Central Administration, I enter (mydomain.xxx.xxx) There is no email sent after I set up the alert. I see the error "Cannot connect to SMTP host "mydomain.xxx.xxx" in the Windows Event log.
I also tried to send and email from PowerShell cmdlet, but it fails.