If you would like to read the other parts of this article series please go to:
Introduction
In part 12 of this multi-part articles series revolving around Exchange hybrid deployment based migrations to Office 365 or more precisely Exchange Online, we took a closer look at the stuff that was configured behind the scene when we ran the hybrid configuration wizard (HCW).
In this part 13, which by the way is the last in this series, we will continue where we left off in part 12. That is we will move an on-premise Exchange mailbox to Exchange Online and then we will test the browser and client behavior and see what to expect when a mailbox has been moved from on-premise Exchange to Exchange Online. Moreover, we will be provisioning a new mailbox in Exchange Online using the “New Remote Mailbox” wizard and the “New-RemoteMailbox” cmdlet. Lastly, I explain what to consider when it comes to decommissioning your Exchange on-premise servers or just the legacy Exchange servers within your on-premise environment.
Let’s get going…
Moving a Mailbox
Now that we have configured a hybrid deployment, let’s test things out to ensure they work as expected. First, we will move an on-premise mailbox to Exchange Online using the “New Remote Move Request” wizard. This can be done by right-clicking on an on-premise mailbox and selecting “New Remote Move Request” in the context menu as shown in Figure 1.
Figure 1: Launching the New Remote Move Request wizard
On the “Introduction” page, click “Next”.
Figure 2: Introduction page in the New Remote Move Request wizard
On the “Connection Configurations” page, make sure “Target forest” is set to “the name you gave the additional Exchange forest”, then enter the FQDN for the Exchange hybrid server that has the Client Access server role installed. Also, enter the credentials for an on-premise administrator and click “Next”.
Figure 3: Connection Configurations page in the New Remote Move Request wizard
On the “Move Settings” page, click “Browse” and then select the target delivery domain (in this case “office365labdk.mail.onmicrosoft.com”). Since, we’re moving a mailbox to Exchange Online, we cannot select the target database (it will be picked randomly). Click “Next”.
Figure 4: Move Settings page in the New Remote Move Request wizard
On the “Configuration Summary” page, click “New” in order to create the remote move request in Exchange Online.
Figure 5: Configuration Summary page in the New Remote Move Request wizard
On the “Completion” page, click “Finish”.
Figure 6: Completion page in the New Remote Move Request wizard
Now, click on the “Move Request” node under the Office 365 tenant node as shown in Figure 7. Here we can see the move request we just created.
Figure 7: Active move requests under the Exchange Online Move Request node
If you open the properties page for the respective mailbox, you can find information such as percent complete, duration, number of corrupted items and the name of the target database.
Figure 8: General tab on the properties page of a move request
If you click on the “Details” tab, you can find information about the source hybrid server, target move request server name, source/target versions and so on.
Figure 9: Details tab on the properties page of a move request
Clicking on the “Log” tab brings you to the place where you can see a complete log of the mailbox move that has taken place.
Figure 10: Move request log under the log tab on the property page of a move request
When a mailbox move has completed, the move request can be cleared by right-clicking on the move request and selecting “Clear Move Request” in the context menu (Figure 12).
Figure 11: Move request completed
Figure 12: Removing the completed move request
When a mailbox has been moved to Exchange Online, the source object will be converted into a mail enabled user object (MEU) and it will be seen as a remote mailbox since it’s an MEU object that is associated with a mailbox in Exchange Online.
Figure 13: Remote User Mailbox object in the Exchange Management Console
In order for e-mail messages that are sent to the respective user via the MEU object in the on-premise Exchange organization to be routed to the mailbox now located in Exchange Online, the routing e-mail address is set to “alias@tenant_name.mail.onmicrosoft.com“ as shown in Figure 14.
Figure 14: Routing E-mail address on the mail enabled user object
Client Behavior after a Mailbox Move
When a mailbox move request has completed, the source object will (as already mentioned) be converted to a MEU object associated with the mailbox now stored in Exchange Online. In the following steps, I’ll explain how a mailbox move to Exchange Online will be detected by the miscellaneous Exchange clients used to access the respective mailbox.
Outlook Clients
An Outlook client that is open during the mailbox move will get the following dialog box when the move has completed.
Figure 15: The Exchange Administrator has made changes that require Outlook to be restarted
When Outlook has been restarted, Outlook will detect that the mailbox has been converted to a MEU object and using autodiscover and the routing e-mail address on the MEU object, the Outlook client will be redirected to the autodiscover service in Exchange Online (autodiscover-s.outlook.com). Since Outlook clients authenticate to Exchange Online using basic authentication, the user will be told to enter his credentials in order to connect to his mailbox in Exchange Online. The user will enter his UPN and password and at the same time, it’s recommended to tick the “Remember my password” box, so that Outlook won’t prompt for credentials next time it’s started.
Figure 16: Outlook prompts for credentials when connecting to the mailbox in Exchange Online
Exchange ActiveSync based clients
When dealing with mailbox moves to Exchange Online, the Exchange ActiveSync client will not be able to automatically update the ActiveSync profile via the autodiscover redirect to Exchange Online. The profile must be reconfigured manually.
Generally, Windows Phone 8 and iOS clients will be able to automatically update the ActiveSync profile, while Android based clients must have their ActiveSync profile recreated.
Outlook Web App
So, when we configured the Exchange hybrid, we introduced a new namespace (hybrid.office365lab.dk), which is associated with the hybrid servers. In addition, we created a new CNAME record (owa.office365lab.dk) that forwards HTTP traffic to hybrid.office365lab.dk, which points to TMG, which again publishes the hybrid servers. Because of this, Exchange users can access their mailbox via “https://owa.office365lab.dk/owa“, no matter if their mailbox is located on an on-premise Exchange 2007 mailbox server or in Exchange Online. The Hybrid configuration has some logic built in that takes care of detecting this based on the organization relationship and the OWA URLs on the Exchange 2007 servers.
When accessing “https://owa.office365lab.dk/owa“, an on-premise Exchange 2007 user will experience the following:
- The Exchange 2007 user will be presented with the Exchange 2010 forms-based login page
- The Exchange 2007 user enters his credentials
- The Exchange 2007 user is redirected to the external URL configured on the Exchange 2007 servers (https://webmail.office365lab.dk/owa)
- The Exchange 2007 user will have transparent SSO and get access to his mailbox via the OWA 2007 interface
Figure 17: OWA 2007
When a user that had his mailbox moved to Exchange Online tries to access his mailbox using “https://owa.office365lab.dk/owa”:
- He will be non-transparently redirected to “http://outlook.com/owa/office365labdk.onmicrosoft.com”.
- On the appearing page, he needs to click on a link (which of course can be added to his favorites).
- Clicking on the link will bring him to login.microsoftonline.com, where the user will enter his UPN
- The user gets redirected to the on-premise ADFS servers
- The user enters his credentials and get access to his mailbox using Exchange 2010 OWA.
Figure 18: Non-transparent OWA redirect URL
Unlike in a pure Exchange 2010 hybrid environment, what will not work in a standard Exchange 2007 hybrid deployment is accessing your Exchange Online mailbox using the existing primary OWA URL (in this case “https://webmail.office365labdk/owa”), that points to the TMG rule that published the Exchange 2007 servers to the Internet. A user with a mailbox in Exchange Online must use “https://owa.office365lab.dk/owa“.
If you want to use the existing primary OWA URL to access both Exchange 2007 and Exchange Online, you would need to create a legacy namespace (i.e. legacy.domain.com) and associate this with Exchange 2007. Then point your primary OWA URL to your hybrid servers just like when you migrate from Exchange 2007 to Exchange 2010/2013.
For more information about your options, when it comes to configuring OWA URL in a hybrid deployment, check this link.
Creating a New Remote Mailbox
Since, you have taken the decision to move all or a portion of your mailboxes to Exchange Online, you will also be interested in being able to provision new users with mailboxes directly in Exchange Online. This can be accomplished using the “New Remote Mailbox” wizard in the EMC or using the “New-RemoteMailbox” cmdlet in the EMS. You can also use more sophisticated methods such as FIM or PowerShell provisioning scripts.
To create a new remote mailbox using the “New Remote Mailbox” EMC, right-click on the “Mail Contact” and then click “New Remote Mailbox” in the context menu as shown in Figure 19.
Figure 19: Selecting New Remote Mailbox in the context menu
On the “Introduction” page, click “Next”
Figure 20: New Remote Mailbox wizard – Introduction page
On the “User Information” page, select the OU in which the AD user object should be created. Then specify the name and UPN and password to be set for the user then click “Next”.
Figure 21: New Remote Mailbox wizard – User Information page
On the “Archive Mailbox” page, click “Next”.
Figure 22: New Remote Mailbox wizard – Archive Mailbox page
On the “Configuration Summary” page, click “New”.
Figure 23: New Remote Mailbox wizard – Configuration Summary page
On the “Completion” page, click “Finish”.
Figure 24: New Remote Mailbox wizard – Completion page
To create a new remote mailbox user with the EMS, use this command:
New-RemoteMailbox -Alias BSteiner -Name “Bern Steiner” -FirstName Bern -LastName Steiner -DisplayName “Bern Steiner” -UserPrincipalName [email protected] -OnPremisesOrganizationalUnit IT
Figure 25: Creating a new remote mailbox user using the Exchange Management Shell
For information around using dedicated PowerShell scripts for the provisioning, check this excellent blog post on the topic.
Decommissioning the On-Premise Exchange Environment
So over time, you may want to decommission the on-premises Exchange environment or at least the legacy Exchange 2007 servers in the Exchange organization. This all depends on whether you have users that may not be moved to Exchange Online for one reason or another. Or, you may have line of business applications etc. that doesn’t support the relaying method provided by Exchange Online (authenticated relaying). Or perhaps there are other reasons (limitations in Exchange Online or legal), that requires a portion of your mailboxes to stay in your on-premise Exchange environment.
When you have an Exchange 2007 environment and have configured an Exchange hybrid, you typically take one of the follow paths:
- Move all mailboxes to Exchange Online, point all on-premise line of business applications, network devices and so on to Exchange Online, configures mail flow to go directly in and out of Exchange Online. In this scenario, you decommission all on-premise Exchange servers, but still use DirSync and ADFS for federation. With DirSync, the on-premise Active Directory is the source of authority, which means you should provision users in the on-premise Active Directory and then have them synchronized to Office 365/Exchange Online. In this cae, it’s usually a good idea to keep a single Exchange 2010 server on-premise, so you can use the Exchange 2010 EMC or cmdlets for the provisioning. Alternatively, you remove all Exchange 2010 servers and have an identity solution such as FIM provision the on-premise Active Directory objects with the required mail attributes in order for Exchange Online to treat them as mail enabled users. Bear in mind that with DirSync enabled, most user/mailbox attributes in Exchange Online are read-only meaning you must write to them via the on-premise Active Directory user/group object.
- Move part of your mailboxes to Exchange Online and keep your Exchange 2010 servers on-premise to support on-premise user mailbox provisioning and line of business applications etc. Move all mailboxes that need to stay on-premise from the Exchange 2007 servers to the Exchange 2010 servers and then decommission the Exchange 2007 servers.
Closing Words
The new version of Office 365 launched on February 27th 2013 (which will have occurred when this article is published). This means that all new tenant sign-ups from this date will be based on wave 15 (Exchange 2013, SharePoint 2013 and Lync 2013). If you want to establish a hybrid with a wave 15 tenant, you must use Exchange 2010 SP3 or later. Although Exchange 2010 SP3 servers are supported as hybrid servers between your on-premise environment and Exchange Online, it’s recommended to use Exchange 2013 based hybrid servers on-premise as these provide you with more advantages over Exchange 2010 based hybrid servers. If you already have a wave 14 tenant, you will be forced to upgrade to the new Office 365 sometime during this year. First time you’re asked to allow Microsoft to upgrade your tenant, you can block the upgrade for two months, but after that time your tenant will be upgraded.
My next article series will cover both these scenarios. Until then enjoy!
This concludes part 13 of this multi-part article (which is the last) in which I explain how to configure Exchange hybrid deployment followed by migrating to Office 365 (Exchange Online).
If you would like to read the other parts of this article series please go to:
