Understanding the admin authentication options when using the EWS API in your migration project

One of the major concerns of the consultant or the project manager, on a migration project, is how long will it take to migrate the mailboxes, and what timelines can they define as reasonable for the migration (or the migration batch) to be finished.

Having that in mind, the conversation around it needs to focus on two major factors:

  • What authentication method should we use
  • How can we minimize (or avoid) throttling

So let’s start by talking about the authentication method.

What are the available authentication methods?

Bittitan MigrationWiz, which of course leverages the Exchange Web Services (EWS) as the API to migrate to and from Exchange 2010+, allows you to use two type of admin authentication methods:

  • Delegation
  • Impersonation

Note: MigrationWiz also allows non admin authentication methods, which we will not discuss on this blog post.

What is delegation and how do I configure it?

Delegation is the authentication method in which the entire migration will be done from the calling account (admin account), that needs to have full access to all of the mailboxes that are being migrated. The requirements for delegation are:

  • admin account needs to be mailbox enabled
  • full access is required to all of the mailboxes being migrated (explicit permissions)
  • a throttling policy should be created and associated with the admin account

In the Bittitan community website you will be able to find instructions on how to configure delegation on the source and target Exchange systems. You can also find there how to create the throttling policy.

By default the MigrationWiz project will try and use delegation, so there’s no other change needed.

What is impersonation and how do I configure it?

Impersonation is the authentication method in which the migration will be done on behalf of the user account, that is being impersonated by the calling account (admin account). For this to happen the admin account needs to be granted rights to impersonate the user accounts being migrated. the requirements for impersonation are:

  • the admin account does not need a mailbox
  • impersonation rights need to be granted to the admin account, over all of the users being migrated
  • a throttling policy is not required but highly recommended

In the Bittitan community website, you will also find instructions on how to configure impersonation on the source and target Exchange systems. The instructions to create the throttling policy are the same you can find on the section above.

The default behavior from MigrationWiz is not to use impersonation, so please make sure you follow the MigrationWiz steps of the article above, to configure impersonation at the project level.

Should I use Delegation or Impersonation?

Now that I described what is Delegation and what is Impersonation, let’s discuss which one should you use for each scenario.

In my professional opinion, that I will detail below and explain why, this is what you should do:

  • If the Exchange system is Exchange Online (Office 365) use Impersonation
  • If the Exchange system is Hosted Exchange (online but not in Office 365) use Delegation
  • If the Exchange system is on premises use Delegation

So now let’s break it down per system.

Exchange Online (Office 365)

The main reason that you should use Impersonation when authenticating against Exchange Online is simple: You cannot create a throttling policy in Office 365 and impersonation is less subject to throttling than delegation. 

I don’t think I need to explain why you can’t create a throttling policy in Office 365, but why is impersonation less subject to throttling? Well the explanation is logic: The subscriptions will be charged against the throttling budget of the target mailbox and not the calling account (admin account), which in other words means that the admin account is doing the migration impersonating each target account and the throttling is being charged to the target accounts, making the limits much more flexible and the migration faster.

Another good thing about Exchange Online is that when you set the impersonation rights, you are of course setting them within the boundaries of your tenant, which is not necessarily true for hosted Exchange systems, as you’ll see below.

Hosted Exchange (not in Office 365)

Now when we look at a hosted Exchange and what admin authentication methods we can have, the main thing you need to keep in mind is that, we will have what the Hoster is willing to configure. And what might that be? Short answer will be Delegation.

Don’t get me wrong, if you manage to get a Hoster (or if you are part of a Hoster Exchange management team and you’re also driving the migration) to either create a throttling policy or configure impersonation associated with a management scope, then what I recommend is:

  1. If you can create a throttling policy then use Delegation and associate that throttling policy to the admin account
  2. If you can’t create a throttling policy but you can enable impersonation with a scope (explanation below) than enable and use Impersonation
  3. If none of the above is possible, then use Delegation

Note: when you set impersonation, if you don’t use a management scope, that will allow the admin account to impersonate any account on that hosted Exchange. That might (and should) be considered a security breach by the Hoster and therefore not possible to configure. Although possible, many Hosters might not be willing to configure impersonation with a management scope, or configure impersonation at all.

On Premises Exchange

Finally when the system is on premises Exchange, you will be able to do all necessary tasks, so why use delegation?

To be able to reach maximum speeds you will still have to create a throttling policy (if you can), so between impersonating and using delegation I do think that delegation and a throttling policy is the best way to go.

Remember when I said “Impersonation is the authentication method in which the migration will be done on behalf of the user account, that is being impersonated by the calling account (admin account).”? Well that’s not 100% true in all cases. Depending on your Exchange version, the subscription might be charged to the calling account, which in essence makes impersonation as effective as delegation in terms of throttling. See the table below:

Exchange version EWSMaxSubscriptions throttling budget accounting
Exchange Online Charged against the target mailbox.
Exchange 2013 Charged against the target mailbox.
Exchange 2010 SP3 Charged against the target mailbox.
Exchange 2010 SP2 Charged against the calling account. Starting with Exchange 2010 SP2 RU4, the budget is charged against the target mailbox.
Exchange 2010 SP1 Charged against the calling account.
Exchange 2010 Charged against the calling account.

Source: EWS throttling in Exchange

From the above table you will see that if you have an Exchange system older than Exchange 2010 SP2 RU4, impersonation and delegation will have the same impact from the throttling perspective. We know that Exchange Online does have a version newer than the one just mentioned, but that is not necessarily true for Hosted Exchange or Exchange On Premises, so have that in mind when planning the authentication methods.

So let me outline the reasons that should make you choose delegation when migrating from an on premises Exchange:

  • the speed of the migration will be highly dependent on the throttling policy, that you can and should create, as well as monitor the Exchange performance during the migration
  • Implementing delegation is easier, specially in cases where you want the admin account to just have rights over a subset of the mailboxes. It’s much easier to just give full access to some mailboxes when compared to give impersonation rights to just some users
  • the way throttling reacts when using impersonation and delegation is different. In my opinion when using impersonation you’re more likely face ErrorServerBusy errors (if you go over the limit of concurrent migrations) and that causes normally more migrations to fail. When using delegation the failures are more likely to happen on the accounts that caused the admin account to over the maximum subscriptions allowed

I know that the explanation above might be a little confusing, specially the last bullet point, but I do highly recommend that you read the EWS throttling in Exchange article, and if you have another idea on what method to use feel free to share it.

I do think that impersonation makes sense only on those scenarios where you cannot fully implement proper delegation, with throttling policies and processes defined to monitor the Exchange server resources during the migration window.

Some useful articles around this subject

The importance of EWS impersonation while using an application account: you will can read the author outline how impersonation is better from an application perspective, and delegation is more oriented towards user access. I also mentions that user access can be controlled and revoked by the end user, which can be true. But on a migration project MigrationWiz will use user access to get into the mailbox and move the data to a destination mailbox, which is exactly what delegation provides you. He also outlines how less complex and global the impersonation setting can be, which is true, but on a project when you only need to migrate a subset of the mailboxes, and where you don’t want to give global access, impersonation will be significantly more complex. In essence this article is a good read that outlines the positives of impersonation and why it’s a good option for application level access and not user level access.

Impersonation and EWS in Exchange: This is an excellent article and a must read, that details how application level impersonation works in Exchange.

So what is the bottom line? At the end of the day it’s still your decision of whether to use delegation or impersonation. I’d say that for some scenarios like Office 365, the decision is a no-brainer (impersonation of course), and in some other scenarios it will depend on what can you configure and what is the simpler and more effective configuration.

Like I stated above I am always more inclined to decide for delegation against Exchange on premises and hosted Exchange, and impersonation against Office 365.

As always I hope this article is helpful, and feel free to share your thoughts.

Understand and script the Get-MailboxFolderStatistics cmdlet

This blog post is going to give you some insight on how you can script the Get-MailboxFolderStatistics cmdlet, but also how to understand it’s output, as well as how is it important to plan a mailbox migration project.

Why are the mailbox folder statistics important to plan a migration project?

That is indeed the first thing you need to consider: Why do I need those statistics? To better answer that let me start by showing you an output of the command.

1

What you see above is the output of a mailbox, where I filtered the Folder Path, the number of items in the folder and sub folders, as well as the size of each folder. So let me bullet point why is this important for a migration project planning:

  • It will give you item counts per user and per item type (Mail, calendar, contacts). Those numbers are important, specially if extremely large, to estimate migration timelines when using the Bittitan MigrationWiz mailbox migration.
  • It will show you the size of every folder as well as the entire mailbox size. This is important to identify which folders are larger on a very big mailbox. I’ve seen examples of some of those folder being considered irrelevant for a migration (i.e deleted items, sent items) and with a flexible tool like the Bittitan MigrationWiz you can filter them out.
  • It will show you not only the folders visible to the end user, but also the recoverable deleted items folder. This might be very important in scenarios where you have in place hold active. It will give you the exact estimate of how many items are under in place hold on the recoverable items, that you will eventually need to move to the same folder on the destination mailbox.

So in summary, and giving a quick example, if you’re moving 1000 mailbox from Exchange Online tenantA to tenantB, you should use the Bittitan MigrationWiz tool, that will be not only fast but also flexible on what you can include and exclude in the migration, leveraging the Exchange Web Services API. To do that the insight of what’s in the mailbox is fundamental to plan the entire migration. You can plan the timelines and how long it will take, what type of licensing you will need at the destination tenant and many other important variables for the project.

How can I filter the output per item type?

When running the cmdlet you need to use the “-FolderScope” parameter to filter the output per item type. That parameter allows you to enter many different folder scope types, the most common being:

  • All
  • Calendar
  • Contacts
  • RSSSubscriptions
  • RecoverableItems

See the entire list in the official Technet article of the Get-MailboxFolderStatistics cmdlet.

Some cmdlet examples

See below some examples on how to obtain specific data:

Get total number of items in the mailbox (does not include recoverable deleted items):

Get-MailboxFolderStatistics user@domain.com | Where-Object {$_.foldertype -eq ‘root’} |ft folderpath, itemsinfolderandsubfolders, folderandsubfoldersize

2

Get total number of contacts in the mailbox:

Get-MailboxFolderStatistics user@domain.com -FolderScope Contacts |ft folderpath, items*, folderandsubfoldersize

3

Note: the above will work for calendar items if you change the folder scope from “Contacts” to “Calendar”

Get total number of items in the Recoverable deleted items folders:

Get-MailboxFolderStatistics user@domain.com| where {$_.FolderType -eq ‘RecoverableItemsRoot’}|ft folderpath, itemsinfolderandsubfolders, folderandsubfoldersize

4

And finally… the script that exports all of this to a csv:

Now that we discussed how important it is to get the statistics, and I gave you same examples on how to run some one line commands to get some insight on the mailbox, I will share with you a script that was done by me and my colleague and friend Alberto Nunes.

Below are the details of what the script does:

  • The script will run the statistics against a list of users that needs to be specified on a file called users.csv (see csv format below). The file needs to be on the same folder as the script.
  • The script runs Exchange PowerShell commands, so make sure you’re connected to the Exchange PowerShell (online or on premises)
  • The script will export the results to a file statistics.csv
  • The script will ask you for a source or destination parameter. The statistics for the recoverable deleted items folders will only be included if you select Destination.
  • This script is provided as is and there’s no guarantee that it will work in your environment.

The Users.csv file:

5

Note: Make sure you name the column A “EmailAddress”

The Script:

Copy the text below (in red) to a notepad. Save it as .ps1 and run it from a PowerShell session connected to Exchange.

#Start Script
Param
(
[Parameter(Position=0,Mandatory = $true)][ValidateSet(‘Source’,’Destination’,’MigrationWiz’)][String]$Location,
[Parameter(Mandatory = $false)][String]$Folder = “.”,
[Parameter(Mandatory = $false)][String]$UsersCSV = “Users.csv”,
[Parameter(Mandatory = $false)][String]$OutputCSV = “Statistics.csv”
)
Get-Date
$ErrorActionPreference = “SilentlyContinue”
$SourceFile = $Folder + “\” + $UsersCSV
$OutputFile = $Folder + “\” + $OutputCSV
$mailboxes = Import-Csv -Path “$SourceFile”
$CSV = @()
Foreach ($mailbox in $mailboxes)
{
Write-Host “Working on $($mailbox.EmailAddress)”

$AllStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress)| Where-Object {$_.foldertype -eq ‘root’}

$ContactStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope Contacts
$TotalContactsItems = ($ContactStats | select -expand ItemsInFolder |Measure-Object -Sum).Sum

$CalendarStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope Calendar
$TotalCalendarItems = ($CalendarStats | select -expand ItemsInFolder |Measure-Object -Sum).Sum

$RSSFeeds = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope RssSubscriptions -ErrorAction SilentlyContinue
If ($RSSFeeds)
{
$TotalRSSFeeds = ($RSSFeeds | select -expand ItemsInFolder | Measure-Object -Sum).Sum
}
Else
{
$TotalRSSFeeds = 0
}

# In the source, we don’t need to know the Size of the RecovableItems
If ($Location -eq “Destination”)
{
$recoverableItems = Get-MailboxFolderStatistics $($mailbox.EmailAddress)| where {$_.FolderType -eq ‘RecoverableItemsRoot’}
[double]$recoverableSize = $recoverableItems.FolderAndSubfolderSize.TrimEnd(” bytes)”).Split(“(“)[1].replace(‘,’,”) |%{“{0:N2}” -f ($_ /1mb)}
}

$TotalMailItems = $AllStats.ItemsInFolderAndSubfolders – $TotalContactsItems – $TotalCalendarItems – $TotalRSSFeeds

$ISSize = $AllStats.FolderAndSubfolderSize.tostring()
[double]$ISSize =$ISSize.TrimEnd(” bytes)”).Split(“(“)[1].replace(‘,’,”) |%{“{0:N2}” -f ($_ /1mb)}

$Output = New-Object PSObject
$Output | Add-Member -MemberType NoteProperty -Name “User” -Value $mailbox.EmailAddress
$Output | Add-Member -MemberType NoteProperty -Name “Location” -Value $Location
$Output | Add-Member -MemberType NoteProperty -Name “TotalItems” -Value $AllStats.ItemsInFolderAndSubfolders
$Output | Add-Member -MemberType NoteProperty -Name “MailboxSize MB” -Value $ISSize
$Output | Add-Member -MemberType NoteProperty -Name “TotalContactItems” -Value $TotalContactsItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalCalendarItems” -Value $TotalCalendarItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalMailItems” -Value $TotalMailItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalRSSFeeds” -Value $TotalRSSFeeds
If ($Location -eq “Destination”)
{
$Output | Add-Member -MemberType NoteProperty -Name “RecovableSize in MB” -Value $recoverableSize
$Output | Add-Member -MemberType NoteProperty -Name “RecovableItems” -Value $recoverableItems.ItemsInFolderAndSubfolders
$Output | Add-Member -MemberType NoteProperty -Name “Total Mailbox Size including Recovable” -Value $($ISSize + $recoverableSize)
$Output | Add-Member -MemberType NoteProperty -Name “Total Mailbox Count including Recovable” -Value $($AllStats.ItemsInFolderAndSubfolders + $recoverableItems.ItemsInFolderAndSubfolders)
}
$CSV += $Output
Write-Host “Completed $($mailbox.EmailAddress)” -ForegroundColor Green
}

$CSV | export-CSV “$OutputCSV” -NoTypeInformation
#End Script

To run the script you need to specify the location parameter:

.\MailboxFolderStats.ps1 -Location Source

.\MailboxFolderStats.ps1 -Location Destination (includes recoverable deleted items statistics)

As always I hope the above is helpful. Thanks for reading.

Office 365 tip: Enable Directory Sync via PowerShell

There’s no easy way to say this. The new Office 365 admin Portal comes with a new way to enable Directory Sync, a wizard that tries to guide you through with a series of questions and suggestions. The end result is bad, to say the least.

 

ADSyncWiz1

The wizard is confusing and the end result is sometimes not the expected. It happened to me several times finishing the wizard just to find out that Directory Sync was still disabled.

In my opinion things like finishing the wizard if you select “1-10” in the number of users of your organization, assuming of course that you don’t want Directory Sync, are not welcome. I understand the “dummy proof” idea behind it, but let’s face it not everything needs to be designed in such way.

ADSyncWiz2

As you can see above once you run the wizard you’ll get a summary report of the results, and links to download  AD Connect and the IdFix tool.

But the purpose of this blog post is to explain you how to get away from the wizard and on a simple command activate Directory Synchronization. Here it goes:

  1. Download and install the Windows Azure Active Directory Module for Windows PowerShell
  2. Connect to Office 365 and run the cmdlets below

ADSyncWiz3

Enable Directory Sync:

Set-MsolDirSyncEnabled -EnableDirSync $true

Verify Directory Sync state:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

I hope the above is helpful. As always, any questions please let me know.

 

Office 365: Script to bulk change the UserPrincipalName to match the Email Address

When you are preparing your local Active Directory, to be synced with Office 365, one of the things you should consider is to make the UserPrincipalName of each user you are syncing to match the user’s email address. Why? Because that is going to be his UserPrincipalName and his primary SMTP address on Office 365.

So there are different ways of achieving this, some more manual than others. The procedure I am going to outline today on this blog post is a two step procedure:

Step 1: Export all UserPrincipalNames and Email Addresses from the local AD to a CSV File.

Step 2: Use that CSV file to bulk change the UserPrincipalNames to match those Email Addresses.

Like I said there are different ways of doing this, and I will probably develop a more elaborated script that can do this in a single step. The reason I went for this two step process is because most of the times customers want to check the CSV generated on step 1, and remove all the users that they don’t want to change the UPN, because those users will not be synced to Office 365.

Before we detail the steps above, make sure that you’ve added additional UPN domain suffixes for all the primary SMTP domains that you will have. See the article “How to add UPN suffixes to a forest” for more information.

Also have a detailed read on the article “Prepare to provision users through Directory Synchronization to Office 365”, to fully understand all the tasks you have to do to prepare your local Active Directory.

Making the UPN’s match the email addresses and have a domain that is validated on Office 365 is just one of the several tasks you have to do.

Now back to the two step process to change those UPN’s.

Step 1:

On step one all you have to do is open a PowerShell module on your local AD, and run the cmdlet below.

#Make sure you Import the Active Directory Module into your PowerShell session before you run the cmdlet

Import-Module ActiveDirectory

#Run the cmdlet to export all the users to a CSV. Change the CSV name and path as appropriate

Get-AdUser -Filter * -Properties UserPrincipalName, Name, EmailAddress | Select-Object UserPrincipalName, Name, EmailAddress | Export-CSV -Path C:\MyADUsers.csv -NoTypeInformation

After you run the cmdlet you should get a CSV like the one shown below:

ChangeUPN1

On the example above you can see that the UserPrincipalName does not match the user’s email address, and therefore needs to be changed.

Once you get the CSV check all users that you want to change and remove from that CSV the ones that you don’t.

Step 2:

Now that you have the CSV with all the users you want to change, all you have to do on step 2 is run the script below. The script will change all the UPN’s to match the email address, based on the CSV file you will use.

#Script to Change the UPN on the Active Directory#
#This script should run from an Active Directory Module for Windows PowerShell#
#Version 1.0 – 06/30/2015#
#Author: Antonio Vargas#

$UserCount = 0

Import-Csv -Path C:\MyADUsers.csv | ForEach-Object {

$UPN = $_.UserPrincipalName
Write-Host “Working on user:” $UPN
Get-ADUser -Filter {UserPrincipalName -Eq $UPN} | Set-AdUser -userprincipalname $_.EmailAddress
$usercount = $usercount +1
}
Write-Host “Number of users on your CSV: $UserCount”
Write-Host “UPN’s Changed”

Copy the entire content above into a notepad, and save it as a .ps1 file.

The script above is a very simple script that will read from the CSV. Before you run the script make sure you import the Active Directory module, as described on step 1, into your PowerShell session.

I highly recommend running the script first against a small group of up to 5 users, and then make sure that the changes were applied successfully. Also you need to take into account that you are changing the UserPrincipalName of the user on your local Active Directory, so make sure to test the access to all internal systems that rely on AD for authentication, before you replicate the change to all of your users.

As always, if you have any questions please let me know.

Office 365 AADSync Password Sync failed: Event 611 System.MissingMethodException

Just recently I installed the Microsoft Azure Active Directory Sync, and faced a strange issue: Password Sync was not working. When a password was updated on premises, those changes were not being replicated to Office 365. I was installing AADSync on a Windows 2008 R2 Operating system.

The Microsoft Azure Active Directory Sync tool event ID’s, that you can see on your server event viewer, are actually very good and make the job of troubleshooting the tool much easier. There is a Microsoft support article on how to troubleshoot AADSync that has all the event ID’s and if you’re having problems with the tool you should definitely have a look into it.

On my scenario, I went to the event viewer and immediately detected the event ID 611, that was stating that the Password Sync was failing for my internal domain, as shown below:

PassSync1

I started trying to understand why, and here’s what I looked at:

  • I had no firewalls between the AADSync Server and the AD Domain controllers
  • Both servers were on the same subnet and with the local firewall disabled
  • AADSync was communicating with the Domain Controllers and all other tasks were working, except the Password Sync feature

So there was no way that this was about networking. So I circled back to the prerequisites of AADSync and found out what the problem was:

I had installed Microsoft .Net Framework 4.5, and it actually was good enough to allow me to install AADSync, and you can actually find a lot of guides out there that state that the 4.5 version is good enough, but when you’re installing on a Windows 2008 R2 it’s not, and I needed to install Microsoft .Net Framework 4.5.1.

Once I upgraded the .Net Framework to 4.5.1 everything started to work.

How to configure mail flow coexistence between GApps and O365 using internal relay domains and mail users

Are you planning to move your e-mail system from Google Apps to Office 365? Do you have a large number of users, and therefore migrate the users in stages, and therefore set up mail flow coexistence between the two systems? Keep reading.

On this blog post I am going to guide you through the process of setting up mail flow coexistence, between Google Apps and Office 365.

There are several ways to achieve the mail flow coexistence, from an Office 365 perspective, such as:

  • The Internal relay domain with mail users method
  • The Criteria Based Routing method

This blog article will guide you through the mail flow coexistence configuration, using the internal relay domain method. This method as some pros and cons when compared to others, such as:

Pros:

  • Easy to configure
  • If the processes are well defined it’s also easy to manage as the migration goes along

Cons:

  • Requires more processes during the migration stage
  • Requires more changes post migration
  • When not using Dirsync or AADsync the users on Office 365 need to be created via the Exchange Admin Centre or the Exchange Online PowerShell, which makes the user creation process more complicated.
  • When you enable a mailbox on Office 365, for a user being migrated, all new e-mails coming from other Office 365 users (and external users if you already changed the MX record to Office 365), will not reach the Google Apps mailbox and stay only on the Office 365 mailbox. This makes that the process of migrating the user data has to be managed in batches of users, and done ideally over the weekend.

In my opinion, if you’re using Dirsync this method is an option you should consider.

Now let’s get what matters: the steps for configuring mail flow coexistence between Google Apps and Office 365.

Step 1 – Validate your domain on Office 365:

Of course if you are moving to Office 365, the first thing you need to make sure is that your domain is validated there, and enabled for Exchange Online.

On my scenario, the domain that I am using is myexchlab.com

1

I am not going to give you a step by step guide on the simple tasks, such as adding and validating the domain on Office 365, to keep this blog post focused on the essential, which is to set up the mail flow coexistence.

As you can see above you need to make sure that your domain is added and validated, and that the domain purpose is set to ExchangeOnline.

2

As you can also see above, on my Google Admin Portal, my domain is also validated and working there, as that is my current production environment.

Step 2 – Create and enable your Office 365 users as mail users

Depending on the way you create the users, they can already be mail users on Office 365, i.e. if you are using Dirsync or AADSync to push your users to Office 365, you should have them as mail users on premises, which will also make them mail users on Office 365.

To sum up, there are two ways to create all your users as mail users on Office 365:

  • If you’re using Dirsync enable them as mail users on premises and push them to Office 365
  • If you’re not using Dirsync you need to create all your users via the Exchange Online PowerShell, or the Exchange Admin Centre, directly as mail users. The reason is simple: In Office 365, it’s not supported to enable a user without Exchange attributes (just a regular MSOL user) as a mail user. The only way to give him Exchange attributes is to enable an Exchange Online license and create him a mailbox.

In my case I am not using Dirsync, so I am going to show you how to create all my users as mail users. To do so you can use a script (let me know if you need one), or do it manually via the Exchange Online management Shell.

Connect to the Exchange Online Powershell, and run the following cmdlet:

New-MailUser -Name “GApps1” -Alias Gapps1 -ExternalEmailAddress Gapps1@myexchlab.com -FirstName GApps1 -LastName 1 -MicrosoftOnlineServicesID GApps1@myexchlab.com -Password (ConvertTo-SecureString -String ‘P@ssw0rd’ -AsPlainText -Force)

3

Repeat the step for each user you want to create.

4

Now I have GApps1 and GApps2 created on Office 365, both users also exist and have their productions mailboxes on Google Apps.

5

The users are also Exchange mail users, which is fundamental to have both an up to date Global Address list on Office 365, and to make the mail flow coexistence work.

I know that this way of creating the users might seem a bit manual, but there are two things you need to consider:

  • Most of you will be using Dirsync, which makes the user creation process much simpler.
  • You can script the user creation via the new-mailuser cmdlet and make your live easier.

Step 3 – Configure the routing domain in Office 365

In order to have mail flow coexistence between Google Apps and Office 365, you need to set up a forwarding address in each Google Apps user you move to Office 365. In order for it to work, the forwarding address needs to be from a sub domain of your main email domain. In my case I will use onprem.myexchlab.com which is a subdomain of myexchlab.com.

To properly configure the subdomain you need to:

  • Validate it on Office 365 and configure it for Exchange Online
  • Create an MX record for that subdomain, that points to office 365
  • Make sure that the users have a secondary SMTP address for that subdomain, that you will use as forwarding address on google

To validate the routing domain, go to the domains section on your Office 365 portal and click to add a domain.

As the domain is a subdomain of your main e-mail domain, the validation should be instant.

Skip the steps to add users, and make sure that you choose Exchange as domain purpose, as sown below.

6

The Office 365 wizard will give you an option to add the DNS records (depending on your domain name provider), or you can just copy and paste the DNS records and add them yourself. The only relevant record that needs to be created, is the MX record.

7

Make sure you verify that the MX record is created.

8

Step 4 – Configure Exchange Online for mail flow coexistence

On the Exchange Admin Centre of your Office 365 tenant, you need to do two things:

  • Configure your main domain as internal relay
  • Create a send connector to send e-mail to your Google Apps

To configure your domain as internal relay, log in to your Office 365 tenant, and on the bottom left click on “Admin > Exchange”.

On the Exchange Admin Centre go to “Mail Flow” and click on the “Accepted Domains” tab.

9

Select your main e-mail domain, in my case myexchlab.com, and click edit.

10

Select “Internal Relay” and click save.

Now let’s create the send connector. On the Exchange Admin Centre, select “Mail Flow” and click on the “Connectors” tab.

11

Click on the “+” to add a new connector.

12

When creating the new connector, select from Office 365 and to your organization’s email server.

13

Select a name and keep the existing options selected.

14

Select “Only when email messages are sent to these domains” and click on “+” to add your main email domain.

15

Enter one (or several) of the available Google Apps MX record as a smarthost.

16

You can check the Google Apps MX records by doing an nslookup to your domain.

17

Untick the always use TLS option and click next twice.

18

Finally enter a valid e-mail address from your Google Apps environment, and click validate. Make sure the test succeeds.

Migration steps

Now that you have Office 365 configured for mail flow coexistence, let me give you a quick overview on the migration steps:

Define a migration batch

The first thing you need to do is define a group of users to be migrated. Because there’s no sharing of resources cross platforms (i.e calendars), I highly recommend you approach your migration batches on a per department basis. You might want to export all e-mail addresses of the users being migrated, into a CSV file, in order to use that file to script all the forthcoming tasks.

Activate the user licenses in Office 365

Once you have your group of users defined, you need to activate an Exchange Online license for them on Office 365. Like stated previously you can script that, but for the purposes of this blog post I will just activate the license manually, as the main goal here is to explain how to set up the mail flow coexistence.

19

Go to your Office 365 admin portal, click on “Users > Active Users”, select the user you want to license and add an Exchange Online license.

20

Via the Exchange Admin Centre you will be able to see that, the user is no longer a mail user, and it’s now a mailbox.

Note: As stated before, all e-mail coming from other Office 365 users, or external e-mail if you changed the MX record of your main domain to point to Office 365, will now stay on the GApps1 Office 365 mailbox and not on his Google Apps mailbox.

Migrate your user’s data

Now it’s time to push all the data from Google Apps to the newly created Office 365 mailbox. And how can you do that? Well the answer is simple: Use the best tool in the market. MigrationWiz from BitTitan.

https://www.bittitan.com/products/migrationwiz/about

21

MigrationWiz will move all your emails, calendars and contacts, from Google Apps to Office 365. In addition you can also move your Google Drive and your Google Vault data, with other types of migrations supported by the same tool.

Set up the forwarding address on Google Apps

Now at the same time you start to move the data, you need to set up a forwarding address on the Google Apps accounts you’re migrating. I’ll be blogging soon an explanation on how MigrationWiz automatically sets that up for you, but for now I will again do it manually on my GApps1 user.

Log in to https://admin.google.com

Go to Users and click on the user you want to set up the forwarding. Click on “Account”.

22

On the Email routing section add the forwarding address. Untick the “Change SMTP envelope”, the “Google Apps email” (leave a copy on the source) and the “Inherit routes from <your domain>”.

Important note: do not leave a copy on the source mailbox, or else when moving the data to Office 365 via MigrationWiz, you might get duplicates.

23

Another thing that you need to make sure is that all the users being migrated have a @onprem.myexchlab.com secondary SMTP address.

Connect the users to Office 365

Once all the data is migrated all you have to do is set up your users to connect to Office 365 and start working there.

BitTitan also has a tool to help you automate that process: DeploymentPro

https://www.bittitan.com/products/deploymentpro/about

DeploymentPro will configure Outlook for all your users, and bring all attached PST files and signatures from the old profile (if applicable).

Test mail flow

Now that we’ve covered all the migration steps, it’s time to test mail flow between:

  • GApps1 that was migrated to Office 365
  • GApps2 still in Google Apps

Test message from the Internet to GApps1 (Office 365)

With the MX record still pointing to Google Apps, we will send a test message from the Internet to GApps1, that was already moved to Office 365.

24

25

As you can see the message got delivered to Office 365.

Test message from GApps2 (Google Apps) to GApps1 (Office 365)

Now let’s send a message from a Google Apps user to an Office 365 user.

26

27

And again message delivered to GApps1 Office 365 mailbox.

Test message from GApps1 (Office 365) to GApps2 (Goggle Apps)

Now the most relevant test, the one this blog post is all about: mail flow between Office 365 and Google Apps.

Let’s reply to the GApps2 email.

28

29

And there you go. Working!

Internet mail flow considerations

On this coexistence scenario, there is no centralized outbound mail flow, which in essence means that Office 365 users will email directly to the Internet, and the same of course will happen to Goggle Apps users. Having said that, you need to make sure that your SPF record is up to date, and reflects that scenario. For help setting up your SPF record, go to the Microsoft SPF record wizard page.

Summary

Most of the configurations described above only need to be done once, but on the migration steps section you will want to automate everything. I’ve seen a lot of companies concerned with things like setting up the forwarding address on Google Apps, or scripting the way you enable licenses for users. One of my next blog post will be how MigrationWiz automates the forwarding address configuration, and you can ping me if you need more information about that, or if you need scripts for things like enabling the licenses on Office 365.

As stated on the beginning of this post, there are other methods to configure mail flow coexistence between Google Apps and Office 365, and I will soon be blogging about them so stay tuned.

Office 365 Public Folders Migration: Why and when to use MigrationWiz and not the Microsoft native tool

Migrating legacy Microsoft Exchange Public Folders to Office 365 is a challenge that many Organizations are facing at the moment, and the first question that comes to mind is: “What tool shall I use?”

From my perspective and experience, you have two valid options to push your Public Folders to Exchange Online:

  1. The Microsoft Native tool
  2. MigrationWiz from BitTitan

Reasons to use the MigrationWiz Tool

When the source is a Hosted Exchange

Most of the steps you need to follow on the Microsoft TechNet article, to migrate the legacy public folders to Office 365, require full control on the source system. No Exchange hoster will give you the control and permissions you need to use the Microsoft Native tool, therefore using MigrationWiz will be the best option in this scenario.

When the source is Exchange 2013

Microsoft states the following, on the official technet article:

“Exchange supports moving your public folders to Office 365 and Exchange Online from the following legacy versions of Exchange Server:

  • Exchange 2010 SP3 RU8 or later
  • Exchange 2007 SP3 RU15 or later”

This means that when the source is Exchange 2013, at the moment there is no official and supported migration path to move the public folders to Office 365, as you can also read on the BitTitan’s blog article, that describes the experience of the Microsoft Exchange expert and blogger Todd Nelson.

Because you don´t need to patch your existing Exchange Servers

As described above, and stated by Microsoft, to run the native tool your source servers need to be patched with at least Exchange 2010 SP3 RU8 or Exchange 2007 RU15. Patching Exchange servers might require downtime, and if you´re moving to Office 365, chances are you will decommission all Exchange Servers, keeping only one for management if you are using AADSync. So why schedule a maintenance window and patch servers there are soon to be decommissioned? MigrationWiz supports major versions with no specific requirements on the service pack or update rollup.

Support for large Public folders

MigrationWiz adds great value, when you have large individual public folders, and/or the total amount of public folder data to be migrated is very large.

But let’s start with the individual public folders. Microsoft clearly states the following, on the native migration TechNet article:

“Before migration, if any public folder in your organization is greater than 2 GB, we recommend either deleting content from that folder or splitting it up into multiple public folders. If either of these options isn’t feasible, we recommend that you do not move your public folders to Office 365 and Exchange Online.”

Which means that they do not support the migration of public folders larger than 2GB, or at least if and when you have a problem with your migration (and believe me, chances are you will), related to folders bigger than 2GB, the Microsoft support will probably give you an answer based on the statement above.

By default the Public folders on Office 365 cannot be larger than 2GB, but as you can see on the Public Folder limits Technet article, that limit can be extended up to 10GB. If you have public folders with more than 2GB (and of course less than the 10GB limit), all MigrationWiz requires is that you prepare your target environment, by following this article.

Regarding the large total amount of data to migrate, the great value of the MigrationWiz tool, when compared to the native tool, is the capability of, in case of error, getting more detailed information, and more importantly, not having to restart a migration. I was forced to restart very big migrations, done with the Microsoft Native tool, after getting very vague errors, and because the Resume-PublicFolderMigrationRequest was not working, to get my failed migration back in motion. As you can imagine having to restart a 400GB Public folder migration that was 50% done, it´s not a good experience 🙂

1

As you can see on the example above, the errors on the MigrationWiz portal are very clear and detailed, which helps a lot when troubleshooting. Public Folder mailboxes in Office 365 have a limit of 50GB per mailbox, therefore, if you´re migrating more than 50GB of data you need to follow this MigrationWiz article.

More details and statistics during the migration

Although with the native tool, you can run a Get-PublicFolderMigrationRequestStatistics, with the “-includereport” option, and export it to csv, that is nothing compared to what the MigrationWiz portal provides you.

2

You can see both the total number and size, per item type, with errors or migrated successfully.

3

There’s also information on the data migrated, items migrated or transfer speed, for you to have a better understanding of how things are progressing and estimate total migration times.

4

You can see the migration history, and all kinds of statistics, including a very useful data and item speed per hour statistic.

All the above is, in my opinion and based on my experience, very important when you are migrating a large amount of data.

It´s easy to migrate

The way I see it, unless you have very good technical knowledge of both Exchange online and on-premises, you should go for a tool like MigrationWiz that makes your life much easier.

I’ve seen a lot of issues when using the Microsoft Native tool (and you can find some posts in my blog on how to solve them), and if you don’t have advance knowledge, and you want to use the tool, you should find someone that has that knowledge and experience, and can assist you with the migration.

To be clear:

Is the Microsoft native tool, to migrate public folders, a good tool? Yes!

Does it work? Yes!

Is it challenging from a technical perspective? Yes!

Reasons to use the Microsoft Native Tool

If none of the above is relevant to you or your Organization, and you are an expert on Exchange online and on-premises, then you can use the native tool.

The bottom line is that, everything I stated on this post is based on the large experience that I have with Office 365, and more specifically with migrating Public Folders to Exchange Online. I´ve helped dozens of Organizations to achieve that, and learned a lot in the process.

I hope this post was helpful and as always, let me know if you have questions!

MigrationWiz: Public Folder migration fails to check destination credentials “No Public folder mailbox found” error

Are you trying to migrate your Public Folders to Office 365 and getting the error below?

1

Of course the first thing I recommend is obviously for you to check if you do have Public Folder mailboxes created in your Office 365 tenant. Log into the 365 portal, click to Admin Exchange, and then go to Public Folders > Public Folder Mailboxes.

4

You might need to wait up to 5/10 minutes after you create the Public Folder mailboxes and before running the MigrationWiz Public Folder project.

Also please make sure your MigrationWizAdmin user has the necessary permissions on the Public Folder structure. Read here for guidance.

Now what if everything described above is configured correctly, and you still have the same “No public folder mailbox found” error? Of course all the configurations described above are mandatory, but the real reason for this post is that something else might cause this error.

If all your users were moved to Office 365, and are accessing the Public Folders on premises, before you move those public folders to Office 365, I am sure you followed the Microsoft official article “Configure Legacy on-premises public folders for a Hybrid deployment“.

To enable the access to the legacy public folders, amongst other things, you need to run the following cmdlet:

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3

What the above cmdlet will do is, at the organization level set the Public Folders to remote, and more importantly, by setting the “RemotePublicFolderMailboxes” parameter and the OrganizationConfig level, it will change the “DefaultPublicFolderMailbox” parameter at the mailbox level, for all user mailboxes.

2

Above you can see that the RemotePublicFolderMailboxes is set to a mailbox called admin.vargas, and in your scenario it should be the name of an on premises mailbox, “dirsynced” to Office 365.

3

And if you look at the DefaultPublicFolderMailbox on your users, including the MigrationWiz admin user, that value will be set for the on-premises mailbox setting to match the “RemotePublicFolderMailboxes” parameters on the Organization Config.

So how does this affect the MigrationWiz project? Simple. Looking at the example above, the DefaultPublicFolderMailbox of the migwizadmin user is an on-premises “dirsynced” to 365 mailbox named “Admin.Vargas”, and that causes MigrationWiz to assume that there is no available public folder mailbox on 365. The solution is simple. Run the following cmdlet on your Office 365 Exchange PowerShell:

Set-Mailbox -identity migwizadmin@domain.onmicrosoft.com -DefaultPublicFolderMailbox PFMBX

4

You can see your Public Folder mailbox name, on your Office 365 Exchange Admin Centre, as shown above.

5

The cmdlet and the output, from the Exchange Online PowerShell.

Once the change is made, retry the MigrationWiz project, and job done!

There are a lot of good reasons for you to be in the scenario described above – Using MigrationWiz under a hybrid scenario, to move your public folders to Office 365 – especially if you have Public Folder with more than 2GB and a total amount of Public Folder data of more than 50GB. I will soon blog about all the advantages of skipping the Microsoft native tool to migrate the public folders and using MigrationWiz. Stay tuned!

Office 365 tips: Automatic DNS records creation when your custom domain is hosted with GoDaddy

Last week I started another Office 365 project. The custom domain to validate is hosted with GoDaddy, so once more I took advantage of the excellent integration feature between Office 365 and GoDaddy.

This feature is not new, but it’s very good and therefore always worth blogging about it.

Click here to see the official statement from Microsoft, about this integration, and a demo video.

Now a quick walkthrough. My domain was already validated, but you can use the integration also for the domain validation, as it creates the necessary DNS record.

After the domain is validated and you set the domain purpose, the Office 365 Admin portal detects that your domain provider is 365, and you can then click on “Add Records” to add your DNS records.

1

Before adding them, you can see the detail by expanding “View the DNS records we’ll add”.

2

A GoDaddy logon window will pop up. Enter your username and password.

3

Click confirm to accept the changes on your public DNS zone.

(Note: Apologies about the Portuguese screenshoots)

4

You will then get the confirmation that the changes were done.

5

And if you login to your GoDaddy account and edit the zone file for your domain, you will see all the new DNS records there.

6

That’s it. As simples as that! Enjoy!

Exchange Active Sync on-boarding to Office 365 – The seamless experience is finally here

For those who are thinking on moving to Office 365, and in what that might mean from a user experience perspective, the release of the Exchange 2013 Cumulative Update 8 (CU8) and Exchange 2010 SP3 Rollup Update 9 (RU9) brings a long expected feature – seamless experience on the on-boarding process of ActiveSync users, to Office 365.

You can read the full details on the article Exchange ActiveSync on-boarding to Office 365, published on the Exchange Team Ehlo Blog.

Instead of duplicating all the information that you can read on the official blog article, i will just give you my thoughts on how this works and highlight the key points.

When a user is moved to Office 365, under a Hybrid deployment, that mailbox on premises is converted to a remote mailbox, and a “RemoteRoutingAddress” of the type User@tenant.mail.onmicrosoft.com is configured for the remote mailbox.

That remote routing address should be configured as a domain name on an existing Organization Relationship “On premises to O365”.

Before Exchange 2013 CU8 and Exchange 2010 SP3 RU9, the experience was only seamless for users via Outlook or OWA. When those users, moved to Office 365, tried to connect to the Client Access server on premises, a mailbox wasn’t found.. so what happened next?

“The Client Access server triggers a query to find the “TargetOWAURL” property present on the organization relationship object for the Office 365 tenant. The “RemoteRoutingAddress” property, present on the remote mailbox, is used to find the correct organization relationship.”

That “TargetOWAURL” is then used by Outlook (automatically reconfigured the profile) or OWA (presents the new URL to the user) to redirect the user to the Office 365 mailbox.

After Exchange 2013 CU8 and Exchange 2010 SP3 RU9, that process will also work when the user is connecting via Exchange ActiveSync, making the experience seamless as well for all the ActiveSync users.

Of course for all of you that, like me, spend countless hours explaining to customers that recreating the exchange partnership on all of their user’s phones, was the only option, and helping on the creation of user guides, this new feature is excellent news.

From my personal perspective it makes perfect sense that, with the Client Access services already using the Organization Relationships and the TargetOWAURL, to redirect Outlook and OWA clients, the capability to redirect ActiveSync clients is now also an available feature.

Of course there are some limitations, such as the device EAS version not supporting HTTP 451 redirects or cross-forest migrations.

I highly recommend that you read the official article, for all the details on this new feature.

Well done for the Microsoft Exchange Product Group! 🙂