Office 365

So I’m deep in the throws of an Office 365 project, and after going thru the process of setting up Exchange Hybrid with on-premise ADFS, testing mailflow, and performing a mailbox move, the next step was working on Retention Policies to migrate email older than 1 year from their Primary Mailbox with 50gb storage to their Online Archive with 100GB of storage.

I tried to enable the archive from the Exchange Online portal as well as thru Exchange online Powershell but didn’t have any luck. With Powershell I was getting the message:

"Can't enable the archive for user because their primary mailbox is located on an on-premises server. To enable a cloud-based archive mailbox for this user, you must use your on-premises Exchange admin center or Exchange Management Shell."

I found this particularly odd because, well, the mailbox WASN’T on-premises any more nor was there any kind of archive mailbox enabled for my test acount.

After digging for hours (which is typically the catalyst for most of these posts) I came across a solution through the Office 365 community which detailed out adjusting the source AD user’s object on-premises attributes in order for the Archive to come online. Again, since this was a hybrid identity design, on-premises Active Directory was the source of truth and directory synchronization was in place to populate the objects in Azure AD / Office 365.

First, we need to modify the msExchArchiveName attribute to reflect the archive name (this can be whatever we want), as well as modify the msExchRemoteRecipientType to 3.

We’ll leave the msExchRecipientDisplayType and msExchRecipientTypeDetails as is – you can find what these means in a post I made here.

Once completed, force a Dirsync

Once complete, we run the Exchange Online powershell to see that the Get-Mailbox command to see the archive has been created

And that Outlook shows our online archive (with the name that we provided)

My current client is getting ready to migrate off of FOPE smarthosts to EOP and there were some questions around how this process goes. And thankfully I can say it’s pretty easy – just point your smarthosts to your MX record, found in the Office 365 portal.

Without delving too much into the process, a fellow O365 admin Mark Kean has written a great blog post on how this process works:

http://marckean.wordpress.com/2013/06/28/smtp-relay-using-exchange-online-protection-eop/

NOTE: You don’t have to setup anther Inbound Connector in Office 365 – this way you avoid needing another SSL certificate. Just use the Hybrid Mail Flow Inbound Connector and add your on-premise IP into the Sender IP Addresses list for the same results.

This process allows you to continue to use onsite applications, MTAs, copiers, etc to process messages from on premise. And you don’t have to setup the arduous SMTP relay through smtp.office365.com via TLS and with an existing account. This relies on the traditional, allowed IP address method to blanket accept everything sent.

I’m happy to say that it even allows you to relay messages from address that don’t even exist in the organization. So lets say you want to send out messages from no-reply@domain.com on an internal mailing system and that mailbox doesn’t exist. EOP processes these messages with no problem.

There’s another great Technet article I like to refer customers to who have questions on the different email methods EOP allows. The article references multi-function devices but this encompasses any number of devices:

http://technet.microsoft.com/en-us/library/dn554323%28v=exchg.150%29.aspx

Update 4/15/15 – Office 365 has increased the allowed maximum message size to 150 MB, giving Office 365 administrators the ability to set the maximum message size of their choosing from 1 MB up to 150 MB. The default maximum message size for Office 365 mailboxes is still 25 MB, and they don’t plan on to changing the setting on existing accounts.
More at https://blogs.office.com/2015/04/15/office-365-now-supports-larger-email-messages-up-to-150-mb/

I’m currently on project finishing an Office 365 migration (yay – I’m finally back together with my true love: messaging!) and we’re in the process of migrating their 50+ domains off of FOPE, as they were initially a Wave 14 tenant, and over to EOP.  Technically, they were automatically migrated to EOP as part of the upgrades in Q3/Q4 2013, however they still have their MX records pointing to either the mail.messaging.microsoft.com or mail.global.frontbridge.com domains, so traffic is being first routed thru FOPE before it makes it to EOP. And if you may or may not know, it’s crunch time and Microsoft wants everyone off by June 1 (if you have an O365 domain):

http://community.office365.com/en-us/w/manage/update-to-mx-records-faq.aspx

As part of determining the impact these MX record changes will have on message flow, the big one is around accepted message size. In FOPE, if a message went over the size limit you could have it qurantined and the messaging administrator could release it to the mailbox, granted your Receive Connector allowed it, and your MaxReceiveSize on your mailbox matched according.

A large debate has come up around Exchange Online limits, as detailed below:

http://technet.microsoft.com/library/exchange-online-limits%28EXCHG.150%29.aspx

In talking with my collegues, there was a lot of confusion around message limits, and in talking with with my contacts in Microsoft, I can finally clear the air on what these limits are. And it’s actually simpler than you think Continue reading “Exchange Online message limits – not that cut and dry!” »