Domain Redirection and BPOS to Office 365 Migration

Posted on Leave a commentPosted in bpos, DNS, domain, exchange, exchange online, Office 365

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 mail.fabrikam.com (where fabrikam.com is your domain in BPOS) which pointed to go.domains.live.com and then when users accessed mail.fabrikam.com they would be redirected to the correct login page for BPOS. Note that this is also possible by setting the CNAME target to outlook.com.

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

So before you start your migration make sure you have changed your CNAME to outlook.com rather than go.domains.live.com and when users visit http://mail.fabrikam.com 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.

Office 365 Hybrid Coexistence and Edge Server

Posted on Leave a commentPosted in 2010, bpos, exchange, exchange online, hybrid, Office 365

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.

Office 365 DirSync Schedule

Posted on 2 CommentsPosted in bpos, dirsync, exchange, Office 365

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.