bpos DNS domain exchange exchange online Office 365

Domain Redirection and BPOS to Office 365 Migration

With Microsoft Exchange Online via BPOS (the precursor to Office 365) you were able to configure a simple CNAME redirection to make access to OWA easier for your users.

For example, you could create a CNAME in DNS for (where is your domain in BPOS) which pointed to and then when users accessed they would be redirected to the correct login page for BPOS. Note that this is also possible by setting the CNAME target to

A problem here though is that if you use then once you complete migration from BPOS to Office 365 the redirection stops working and when your users visit they get and not OWA!

So before you start your migration make sure you have changed your CNAME to rather than and when users visit they get OWA both before and after the migration.

This recommendation also applies to academic organisations moving from Live@Edu to Office 365 for Education.

2010 bpos exchange exchange online hybrid Office 365

Office 365 Hybrid Coexistence and Edge Server

One of the delights in my job is when Microsoft give me a call and ask me how something works in one of their products! Such a call came today and it involved get Office 365 hybrid coexistence working with an Edge Server.

Exchange Server Deployment Assistant does not have the answer to this issue; it always refers to a Hub Transport server within the organization. But it was an interesting challenge, as the last time I tried to get this working I got a “a local loop detected” error.

In brief, its is possible to use Edge Server as the coexistence server between your organization and your Office 365 tenant, you just need to make sure that everything you would create on the Hub Transport is either configured on the Edge Server (receive connectors and certificates) or created within the organization and replicated to the Edge Server via EdgeSync (send connectors, remote domains, accepted domains).

The reason for “a local loop detected” error was down to having the service domain for the Office 365 tenant configured as Internal Relay (as it needs to be) and not having a Send Connector on the Edge Server that pointed to the Office 365 infrastructure.

Update 26 Oct 2011

In the above I wrote that the Office 365 tenant domain as configured on-premises needs to be internal relay. This is only required if your on-premises org contains Exchange 2003. If the minimum version of Exchange installed on-premises is 2007 then the domain can be Authoritative. This is because with 2007+ you can forward emails to an authoritative domain using contact or remote-mailbox objects and a send connector for the domain.

bpos dirsync exchange Office 365

Office 365 DirSync Schedule

The DirSync process sync’s every three hours by default, with  a random number between 1 and 10 minutes is added to the SyncTimeInterval to provide an additional time buffer to this three hour period.
This schedule can be changed by editing Microsoft.Online.DirSync.Scheduler.exe.Config in C:\Program Files\Microsoft Online Directory Sync. Change to read a different value for hours:minutes:seconds and restart the Microsoft Online Services Directory Synchronization Service.

Note that increasing the time sync interval will result in changes to the Active Directory not being synced until this time period has passed and so the longer the interval the greater risk that objects disabled or removed in the on-premise Active Directory are not replicated to Office 365 and therefore remain as a valid account within Office 365.