Skip to content

Tag: SharePoint

Integrating SharePoint On Premises With BPOS and Exchange Online: Part 2 – Inbound

A few weeks ago I posted an article on how to get on premises SharePoint working with BPOS for mail delivery (alerts, etc.). Historically, inbound email is something that is significantly trickier than outbound, but with hosted Exchange, I’d suggest that the two roles are switched in terms of difficulty. There are however still a couple of extra hoops that have to be jumped through, and I’ll try to guide you through them here.

Firstly, allow me to say that SharePointGeorge has an excellent article out there on setting up incoming email when everything is on premises. In addition, BPOS Tutor had an article on using distribution lists that I was able to make use of while preparing this.

1. Set Up the SMTP service

For the purposes of this article, I’m going to assume that you’ve already done this when you set up outgoing mail. If not, I’ll refer you to my article linked above, or SharePoint George that will walk you through the requisite steps. Once it’s done for outgoing email, you don’t need to touch it for incoming.

2. Configure the SharePoint Farm to Accept Incoming email

First,you’ll need to navigate to Central Administration,and get into the System Settings section. Once there, select “Configure incoming e-mail settings” in the E-Mail and Text Messages section.


There are a number of settings here that will change a bit from what is the typical guidance out there. I’ll try to explain each configuration item, and what it means. Firstly, I’ll show you a completed configuration:


Enable Incoming E-Mail – Well, that’s pretty straightforward, do I turn on incoming email or not? When you turn it on, SharePoint simply monitors an SMTP drop folder for any messages. If it sees one, it will pick it up, and if the destination name matches a list, it will get delivered. It’s really that simple.

The settings mode lets you choose where the drop folder is. The Automatic setting is normally fine, but if you wanted to use a drop folder in a non default location, or on another server, you would select advanced and enter the desired folder. When the configuration is saved, SharePoint will also try to set the appropriate file system rights on that folder (see George’s blog for more details). I set advanced just so I see the path explicitly.

Directory Management Service – This one normally takes a fair bit of configuration to get working, but when we’re using BPOS, it’s easy – we just set it to no. This is a service that sets up contacts and distribution groups in Exchange, and although we’re using Exchange, it’s hosted, and don’t have access to that feature. We will be creating these manually.

Incoming E-Mail Server Display Address – This is the domain that the list email addresses will use. We’re going to change this. It will default to However, even if that address is available externally, we don’t want to be accepting mail from everyone. The IIS SMTP service has no real spam or virus protection, so we want all of our email to go through our hosted Exchange server. The best approach is to use the same domain as your other BPOS users.

E-Mail Drop Folder – As mentioned above, this is the folder that will be monitored for incoming email. If you don’t know if you should change this, then don’t… the default is likely fine.

Once you’re done, click OK to save the configuration. SharePoint is now set up to configure incoming email. Steps 3 and 4 will need to be repeated for every list/library that will accept email.

3. Configure Library to Accept Incoming E-Mail

Navigate to a library that you want to have accept incoming email. From the ribbon, select “Library” (or List..), and then select Library Settings.


Next, under the Communications Column, click the “Incoming e-mail settings” link. You should see a screen similar to the following:


Most of the options are self explanatory, so I won’t go into detail here. The most important ones are of course in the Incoming E-Mail section, which lets you turn it on or off, and lets you specify the address of the list. The address is important, as it will need to match what we do in BPOS in step 4, and it is also important that it is global across the farm (and of course the domain). That name can’t be repeated, so choose wisely. A naming policy is a good idea here.

Once you have the settings the way you want them, click OK, and your list is ready to go. Now it’s on to BPOS.

4. Configure the Address in BPOS

This is where it gets interesting. What we want to do is to have BPOS accept email from internal (and possibly external) senders, and then turn around and deliver them to out IIS SMTP service. Usually, we could set up a contact in Exchange and use mail forwarding to do this for us, but there is no mail forwarding capability in BPOS. So how do we accomplish this? Instead of using mail forwarding, we’ll set up a distribution list with one member, and let it work its magic that way.

The first thing that we need to do is to log into the admin portal at Once in click on the Service Settings tab, and then click on the Exchange Online subtab. From the right hand Actions section, click the “Add new contact” link. You then need to add your contact, which in effect is the library that we enabled in 3 previously:


Most of the fields are cosmetic (they will appear in the GAL), but the most important one for our purposes is the E-Mail address. note that this address is NOT the same as the one that we configured for the list, but includes the server name as well. This is important as BPOS needs to deliver the mail to that server. It is also important that that server address is available to BPOS (on a public DNS). This represents one half of the equation. In the next step, we’ll configure BPOS to accept the email for the list’s address by using a distribution list.

Once ready, Save your changes, and then click on the Distribution Lists link on the left of the screen. From the Actions section on the right, click “New distribution list”.


The Email Alias used here must match the one used in 3 above, and. The display name is relatively unimportant, but again will be available to the GAL. Once you save this screen, you should be ready to go.

It’s worthwhile to describe the flow of what happens. When an email is sent from a user, external or internal, the originating server will look for an MX record for the address to the right of the @ symbol. That MX record will point to your BPOS server. The BPOS server will accept the name, as it matches the distribution list that you created in step 4. The message will then be distributed to the members of the list, in this case one member at the precise SMTP address of the server farm. BPOS will send the message to the SMTP server running on the farm, where it will be deposited to the drop folder. Finally, the timer process in SharePoint will pick up the message and deposit it into the appropriate library.

Nothing to it…. Smile


Moving To Cloud Based Email–My BPOS Story

When I first stuck out on my own (OK…some time before I struck out on my own..), I knew that I was going to need to come up with a good email solution. My requirements extended beyond those of the consumer market, and ultimately I needed the power and control that commercial email system would offer. I really didn’t know Exchange very well, and I wasn’t about to set up a Domino server (which I knew very well) as it was no longer the direction I was heading in.

I signed up with a hosted Exchange provider. This worked quite well, and was very reliable, but I quickly bumped into size limitations and integration problems. I think that at the time the maximum size mailbox was 25 MB.  I also wanted to gain experience with Exchange, so I bit the bullet and setup up a full domain with Exchange 2003 (including a Blackberry BES server) in my basement. That setup ran (in various guises) from mid 2006 to this past weekend. Initially it was comprised of multiple Exchange servers on virtual machines (required for remote Exchange access with 2003) to a single Exchange server without the BES after upgrading to Exchange 2007.

Hosting my own Exchange server was instructive, but ultimately a pain. My home internet connection is a consumer plan, and my service provider implemented multiple approaches to prevent any server hosting. This initially included blocking SMTP traffic inbound and ultimately (at a particularly bad time) blocking outbound SMTP. I quickly found workarounds to these problems (if you’re interested, I’ve used DynDNS for years, and I find their service to be exceptional. I’d recommend them in a heartbeat), but each one of these represented a significant drag on my time,and I’m not getting any younger.

In addition to the active blocking attempts,consumer ISV service isn’t exactly industrial grade. To be fair, they don’t claim that it is. In fact, ISPs typically go out of their way to not promise uptime reliability. Far too frequently after an outage, communication or power, my automatic DNS synchronizer wouldn’t update quickly enough and mail flow would be interrupted. Backup was another maintenance headache – yes it was getting done, but I had to have the infrastructure to support it, etc. All of this, and a few other things have prompted me to keep an eye open for alternatives.

My company is a Microsoft Online partner. We initially signed up to this program in the early days because of our extensive work with SharePoint, and recently, we have targeted online services as a significant growth area. One of the packages offered in Online Services is BPOS – The Business Productivity Online Suite. Simply put, this is hosted Exchange, SharePoint, Unified Messaging, and Live Meeting. All of this is offered at a very reasonable rate – $12.50 per user per month.

I decided last week to take my home Exchange system and migrate it to BPOS. The process went incredibly smoothly. The BPOS portal lays out all of the steps, but it can be a little confusing. I’ll quickly summarize them below.

1. Sync the Active Directory with BPOS

This sets up a one way synchronization between your Active Directory, and your BPOS Active directory. To be sure these are 2 different directories, and this just allows for simple user maintenance in the cloud. This step is not required for operation, but it is required for mailbox migration. One annoyance here – the synchronization tool must run on a domain joined Windows server running a 32 bit (!!!) OS. Since I only have 64 bit server set up, I had to spin up a new one. Ultimately, I would hope this was replaced by some sort of claims based model.

2. Set up your domain records

There are a number of steps here that are well documented in the setup section. These steps will allow your Outlook clients to auto discover your hosted Exchange mailboxes.

3. Migrate mailboxes

There is a tool that sets all of the appropriate user records, migrates mailbox content, and sets up email forwarding for the migrated users. It’s a VERY good idea to clean up all of your old junk before migrating. I, of course didn’t. That said, my largest mailbox (~2GB) took only about 6 hours to migrate. During the migration period, mail is still delivered to the on premises server, and it is kept both locally and in the cloud for migrated users. If a migration fails, it can be rerun and will pick up from where it left off. Once a user is migrated, and tested to be working, you use the tool to remove the mailbox from the on premises server, which will also remove forwarding. All mail will be delivered to the hosted mailbox.

3.5. Optionally, set up handheld connections to the hosted mailboxes.

4. Set Domain Records

Once all mailboxes have been migrated, set your domain’s MX record to now point to the hosted server, and use the administration portal to set it as authoritative, and to allow incoming mail. Once this is done there will be a lag while the changes propagate through the internet. Mail will not flow for a period of time, so don’t be alarmed.

5. Shut down your on premises Exchange server

…and rest peacefully.

Performance on the BPOS system has been great, and there appear to be no capacity issues. The per user mailbox limit can be set on a per person basis and the maximum is 25 GB. My mailbox is less than 2GB, and I do next to nothing to keep it cleaned out.

The only potential problem I see with it is integration. The Hosted server IS out in the cloud in a different domain, and therefore can’t reach back into the internal systems when necessary. For example, if running in a coexistence mode, free/busy time searches won’t work between the two groups of users. Also, on premises servers that need to send email won’t be able to use the hosted server to do so. Again, I hope that the promise of claims based authentication will help to alleviate these issues going forward.

BPOS is still using the 2007 Suite of products… Exchange 2007 and SharePoint 2007. They are slated to be moved to 2010 this fall, and I’m anxious to see what that will bring. When I know, I’ll certainly be posting back here.

I’m very happy with the results I’ve achieve, and heartily recommend it to any small-medium sized business. In fact, given the cost savings that can be achieved, I can’t see any reason why you wouldn’t want to go this route.

Leave a Comment
%d bloggers like this: