If you would like to read the other parts in this article series please go to:
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 1)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 2)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 3)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 4)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 5)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 6)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 7)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 9)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 10)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 13)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 15)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 16)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 17)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 19)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 21)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 22)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 23)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 25)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 28)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 29)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 30)
Introduction
In part 30 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we took a look at the mailbox migration options at our disposal, when moving on-premises Exchange mailboxes to Exchange Online in an Exchange hybrid deployment and perform actual mailbox migrations.
Let’s get going…
So in the last part of this article series, we moved a small batch of mailboxes from Exchange on-premises to Exchange Online. With the migration batch job completed, let’s click on the “mailboxes” tab. Here we can see that the mailbox type for the respective mailbox users has changed from “User” to “Office 365” indicating the mailbox is now stored in Exchange Online. Later on, we will take a closer look at what has changed behind the scene.
Figure 1: Office 365 based Mailboxes
When a migration batch has completed, it’s recommended to delete it so that errors don’t occur should the same users be moved again.
Note:
When you delete a migration batch, the migration endpoint that was created as part of the first migration batch will not be deleted and can be re-used for later migration batches.
You can find the migration endpoint by clicking the dots (“…”) in the migration dashboard or by connecting to Exchange Online using Windows PowerShell and run:
Get-MigrationEndPoint | fl
Figure 2: Migration endpoints page
Figure 3: Migration endpoint details in Exchange Online using Windows PowerShell
Using the Exchange admin center on an Exchange 2013 hybrid server on-premises
To move mailboxes to Exchange Online using the Exchange admin center on an Exchange 2013 hybrid server in the on-premises environment, we need to go to “recipients” and click “mailboxes” as shown in Figure 4. Here we can select the mailbox or mailboxes, we wish to move to Exchange Online followed by clicking ”To Exchange Online” under “Move Mailbox” in the “Action Pane”.
Figure 4: Selecting user mailboxes that should be migrated to Exchange Online
This launches the “new migration batch” wizard and on the first page, we need to provide the credentials for a user that is a member of the “Organization Management” role group in our on-premises Active Directory. When the credentials have been verified successfully, we will be directed to the same mailbox migration batch wizard that I took you through when we initiated the migration batch directly from Exchange Online in the previous article. For this meaning, we will not go through the remaining steps here.
Using Remote PowerShell connected to Exchange Online
If you want to use Remote PowerShell to migrate user mailboxes, you first need to connect to Exchange Online using Windows PowerShell. You can do this using:
$LiveCred = Get-Credential
In the appearing dialog box, enter the credentials for a Global Administrator in the Office 365 tenant and then run the following command:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection
When the session has been created, you can import using this command:
Import-PSSession $Session
Now that we are connected to Exchange Online, we first need to create the migration endpoint. To do so, first enter the following and then specify the credentials of an account that is member of the “Organization Management” role group in the on-premises Active Directory.
$OnPremCreds = Get-Credential
You can now create the migration endpoint with this command:
$MigrationEndpointOnPrem = New-MigrationEndpoint -ExchangeRemoteMove -Name OnpremEndpoint -Autodiscover -EmailAddress [email protected] -Credentials $OnPremCreds
You will need to replace the domain part in the email address with the one used in your environment.
In this example, we will migrate all users listed in a CSV file located on our system partition:
$OnboardingBatch = New-MigrationBatch -Name MigrationBatch1 -SourceEndpoint $MigrationEndpointOnprem.Identity -TargetDeliveryDomain azurelab.mail.onmicrosoft.com -CSVData ([System.IO.File]::ReadAllBytes(“C:\MigrationBatch1.csv”))
To start the migration batch, we use the following command:
Start-MigrationBatch -Identity $OnboardingBatch.Identity
For details around how the CSV file should be constructed, see this piece of TechNet documentation.
A Look at the Migrated Mailbox Users
Let’s take a look at what happens behind the scene for a mailbox user that has been moved to Exchange Online.
As mentioned back in a previous part of this article series, when you run the hybrid configuration wizard (HCW), the SMTP address “[email protected]“ is added to the default e-mail address policy so that it can be stamped as an additional proxy address on the mail objects in the organization.
Figure 5: Exchange Online routing address stamped on user mailboxes in on-premises Exchange organization
When a mailbox is moved to Exchange Online, the source mailbox user object is converted to a mail user enabled (MEU) object and the secondary proxy address “[email protected]“ is set as the external e-mail address. Back with Exchange 2010 based hybrids, the mailbox would be removed from the mailbox view and could instead be found listed as a Remove User Mailbox under the “Recipient Configuration” > “Mail Contacts” node.
With an Exchange 2013 based hybrid deployment, it can still be found under the “mailboxes” tab as an “Office 365” mailbox type as shown in Figure 6.
Figure 6: Mailbox type for move mailbox
MEU objects are required in an Exchange hybrid in order for mail flow, availability lookups and autodiscover to work seamlessly between the on-premises Exchange organization and the Exchange Online organization in Office 365. As some of you might know, when an Exchange client such as Outlook queries availability of another mailbox, it will use autodiscover to find the Exchange organization in which the mailbox is located. For typical on-premises Exchange organization, the availability information will be retrieve on the local Exchange servers. However, in an Exchange hybrid deployment the autodiscover service will detect the MEU object and send the request on to the respective domain based on the external email address. So when an on-premises mailbox user queries availability for a mailbox in Exchange Online, the request will be sent to “[email protected]“ as this will be set as the target (forwarding) address during the mailbox to mail user conversation process.
Figure 7: Remote routing address of on-premises mail-enabled user with mailbox in Exchange Online
Assigning an Exchange License to Mailboxes in Exchange Online
When mailboxes are moved to Exchange Online, assigning an Exchange license to them is not part of the process. This must be done post migration before the grace period expires (currently 30 days). You can do this manually through the Office 365 Portal, you can script it or you could have it based on group membership or an attribute check and then have this logic implemented in the on-premises provision solution used within the organization.
Note:
You can only access your mailbox during the grace period of 30 days using the Outlook client not with the OWA web mail client unless you go directly to the OWA URL in Exchange Online (outlook.office365.com/owa).
Even for large batches of users, the manual method via the Office 365 Portal is quite efficient as you can create a filtered view that only lists users with a mailbox but no Exchange license assigned. To do so, open the Office 365 Portal and then click “Active Users” in the left navigation pane. In the “Select a view” drop-down menu select “New view”.
Figure 8: Creating a new filtered view
Enter a meaningful name for the new filtered view (I call it “Unlicensed Users with Mailbox”) and tick the “Users with Exchange Mailboxes or archives and no licenses” in the bottom of the page and click “Save”.
Figure 9: New filtered via configuration
Now select the new filtered view in the drop-down menu as shown in Figure 11.
Figure 10: Selecting the new filtered view
You will have users with the set condition listed accordingly. Select the users and click “Edit”.
Figure 11: Users with a mailbox and no license
On the “Details” page, click “Next”.
Figure 12: Details user property page
Set the “User location” (this is required in order to proceed) and click “Next”.
Figure 13: Settings user property page
Now tick the respective licenses you wish to assign to the selected users and click “Submit”.
Figure 14 Assigning the respective licenses to the users in bulk
In order to assign licenses using a scripted approach, you can find useful sample scripts in the Office 365 section of the TechNet Script Gallery.
This concludes part 31 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.
If you would like to read the other parts in this article series please go to:
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 1)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 2)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 3)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 4)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 5)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 6)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 7)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 9)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 10)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 13)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 15)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 16)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 17)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 19)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 21)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 22)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 23)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 25)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 28)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 29)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 30)