Connecting on-premise SharePoint to Exchange Online

My company is in the process of migrating our on-premise email system (Exchange 2003!) to BPOS/O365/Exchange Online/other acronyms here. Since we use a slightly non-standard email routing system with SharePoint, I'd been having some difficulties figuring out how all the pieces would come together to make this happen. O365 Support has been...well...there.

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 facesfirewalls, now is the time to do so.

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!

Adventures in SP2013

I've finally gotten around to setting up a demo VM of SharePoint 2013. Of course, it was necessitated by looking forward to see if we could utilize it to solve a problem a user is having now, so I haven't exactly gotten to dance around in the snowflakes and stare in awe and wonder at the freshness of it all... That said, I'm very much liking what I see so far.

I've had a couple of minor gotchas arise during the testing. For starters, I'm using CriticalPath's SP2013 VM setup guide (free registration required). It's been really good so far, though I got briefly thrown off track due mostly to a dumb mistype on my part and a red herring in the guide. When setting up your new users in Active Directory, the CriticalPath guide includes a PowerShell script and annotations in the document which state that it will handle SQL permissions.

This is not accurate. It's also not a problem, because the SP installer does it for you (provided the account you run the SP installer under has permissions to write to the database to begin with). Just provide the account/credentials for your would-be farm account, and SP will set all the privileges accordingly. That's nice.

When SP offers to create your first site collection, I was thrown off slightly by the fact that the installer defaults to the /sites/ managed path. I had assumed that the root site collection (eg - "/") was going to be created by default, and so after the configuration wizard completed and I couldn't visit http://mynewvm/ but http://mynewvm/sites/test worked, I was a little puzzled.

Part of my testing scenario involved setting up some metadata terms for working with refiners. It was easily done in the site settings for my test site, but then when I was nosing around in the Managed Metadata Service application, I couldn't seem to edit the term store at all. After a short time browsing the Internet unsuccessfully, the reason finally dawned on me - I didn't have permissions to edit the global term store because nobody is defined as a Term Store Administrator! I added myself here, saved the changes, and voila - I can now start creating termsets.

More later.

SharePoint DB GUID cleanup

With the help of well-publicized articles by Todd Klindt and his bro-crusher Shane Young, I had some admin time today to work on getting my environment set in order. Our Production SP2010 environment was put in place by consultants, which means, amongst other things, databases with long, frilly names.

For reference, see here. (Pictures hosted from the dead SharePoint911 server, go poke Shane about migrating his blog content to Rackspace!)

Shane's article on the Search Service Application DBs indicated that on a vanilla, non-used database, migrating your Crawl Store and Property Store DBs took a base of six minutes. When my databases were going upwards of 25 minutes, I decided to look into it more closely. As it turns out (this isn't entirely unexpected), when SharePoint creates its replacement databases, it ignores the Model DB settings and sets its growth to the agonizing standard of 1 MB increments...and then of course, it proceeds to jam all your old search terms/cache into that DB, one MB at a time.

Save yourself some agony - if you plan to do this yourself, once you apply your changes to the topology, open SQL Server Management Studio and fix the growth settings on both DBs to save yourself present and future headaches.

The infamous SP2010 User Profile Service

One of our contractor consultants is responsible with part-time administration tasks, and he assisted to a degree with the setup of our SP2010 environment. He struggled for some time with the configuration of the import of user profiles (we have five domains to pull profiles from currently), but last week he successfully got it configured and got profiles imported.

Thing is though, I was trying to look at some information about the profile import and anytime I'd open the Connections page, I would get the well-traveled "The query returns nothing" error.

After poring over his configuration for some time, I finally got tired of fussing with it and just nuked everything he did. Using the de facto guide published by Spencer Harbar (and some incremental fixing of Event Viewer log errors in trying to fix the original morass), I was able to successfully configure the User Profile Service Application in under 3 hours (had to add a NIC to the server in order to set up an SSL instance of MySites to save for later).

If you want something done right...